How to avoid inout type constructor with Optional type wrapper undoing string type
Steven Schveighoffer
schveiguy at gmail.com
Sun Jul 29 12:30:58 UTC 2018
On 7/28/18 6:06 PM, aliak wrote:
> On Friday, 27 July 2018 at 14:52:20 UTC, Steven Schveighoffer wrote:
>> On 7/23/18 2:39 PM, aliak wrote:
>>> Hi,
>>>
>>> I'm playing around with an Optional wrapper type. It stores a type T
>>> and a bool that defines whether a value is defined or not:
>>>
>>> struct Optional(T) {
>>> T value;
>>> bool defined = false;
>>> this(U : T)(auto ref inout(U) value) inout {
>>> this.value = value;
>>> this.defined = true;
>>> }
>>> }
>>
>> Don't use inout here. The point of inout on the constructor is to
>> *transfer* the mutability of the parameter to the struct instance. But
>> you want to simply copy the type into the struct (an
>> immutable(Optional!T) is quite useless, no?)
>>
>> Just use U, not inout(U), and don't put inout on the constructor.
>>
>
> But then it only works for mutable Optional right? Why would an
> immutable(Optional!T) be useless? Data can be "forever" empty or a
> certain value.
What I meant was that string is actually mutable (the data isn't
mutable, but the string can be re-assigned to another one), so
Optional!string is more useful than immutable(Optional!(char[])). I
shouldn't have said that immutable(Optional!T) is useless, you are
right, and it wouldn't make sense for the defined flag to change there
anyway.
But I see a problem here. string *is* mutable, yet, the parameter is
accepted as inout(char[]). This seems unreasonable, I may want to
preserve the head mutability. I didn't realize IFTI would do this. May
be a bug, but I'm not certain.
But you have it as auto ref, which means since you only sent in rvalues
of strings, you didn't test the ref-ness of it. Indeed, if you do:
string s = "hello";
auto a = defined(s);
you get what you expected!
This doesn't make a whole lot of sense. I wouldn't expect different
types using IFTI this way. I'd recommend filing a bug on inout and IFTI.
There isn't a good way around this...
-Steve
More information about the Digitalmars-d-learn
mailing list