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