Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable.

Optional!(immutable int) a = some(3);
a = none;

I used to do this via a dynamic array and opAssign would recreate the array

struct Optional(T) {
  T[] bag;
  opAssign(T t) {
    bag = [t]
  }
}

But then there were problems with inout, namely:

Error: variable `Optional!(inout(A)).Optional.bag` only parameters or stack based variables can be inout

So I changed it to a stack variable (prefer this anyway, it's not only because of the inout error) but now I'm unsure if I'm violating the type system. Basically I'm now storing T as Unqual!T, but what I'm looking for is a Rebindable implementation that's for value types as well. Is this possible?

Now I do this:

struct Optional(T) {
  Unqual!T value;
  opAssign(T t) {
    value = cast(Unqual!T)(t);
  }
}

I put up a PR if anyone wants to see the code. Any pointers, tips would be highly appreciated:

https://github.com/aliak00/optional/pull/13/files#diff-cb543fea6a0b5eeb07b6aac9f068e262

Cheers
- Ali

On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:
> struct Optional(T) {
>   Unqual!T value;
>   opAssign(T t) {
>     value = cast(Unqual!T)(t);
>   }
> }

Consider this case:

Optional!(immutable int) a = some(3);
immutable int* p = &a.value;
a = some(5);

Clearly the above code shouldn't compile - you can't overwrite the value, as it would break immutability. If you want to support both immutability and reassignment, you will need to use redirection - either an array as you did, or a pointer.

As for the problems you've had with inout, I wrote this template a few years back:

template SubstituteInout(FromType, ToType) {
    static if (is(ToType == inout(SubType), SubType)) {
        alias SubstituteInout = CopyTypeQualifiers!(FromType, SubType);
    } else static if (is(ToType == SubType*, SubType)) {
        alias SubstituteInout = SubstituteInout!(FromType, SubType)*;
    } else static if (is(ToType == SubType[], SubType)) {
        alias SubstituteInout = SubstituteInout!(FromType, SubType)[];
    } else static if (is(ToType == SubType[n], SubType, size_t n)) {
        alias SubstituteInout = SubstituteInout!(FromType, SubType)[n];
    } else static if (is(ToType == SubType[KeyType], SubType, KeyType)) {
        alias SubstituteInout = SubstituteInout!(FromType, SubType)[SubstituteInout!(FromType, KeyType)];
    } else {
        alias SubstituteInout = ToType;
    }
}

unittest {
    static assert(is(SubstituteInout!(const(string), int) == int));
    static assert(is(SubstituteInout!(const(string), inout(int)[]) == const(int)[]));
    static assert(is(SubstituteInout!(const(string), inout(int)) == const(int)));
    static assert(is(SubstituteInout!(const(string), inout(int)*[][3][int]) == const(int)*[][3][int]));
    static assert(is(SubstituteInout!(const(string), inout(int)[inout(string)]) == const(int)[const(string)]));
}

I really should get around to making a PR for it...

--
  Simen

On Sunday, 25 March 2018 at 23:00:11 UTC, Simen Kjærås wrote:
> On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:
>> struct Optional(T) {
>>   Unqual!T value;
>>   opAssign(T t) {
>>     value = cast(Unqual!T)(t);
>>   }
>> }
>
> Consider this case:
>
> Optional!(immutable int) a = some(3);
> immutable int* p = &a.value;
> a = some(5);

Of course, if Optional offers no way to get a reference to the wrapped value (say, if a.value is an @property function that doesn't return ref T), then using Unqual internally is safe*.

Someone with knowledge of the internal layout of Optional might use tricks like *cast(immutable(int)*)&a, but in that case they're breaking the type system anyway, and one simply cannot negotiate with terrorists.

*actually, this may not be 100% true, in cases where T.opAssign does weird things. Consider:

struct Foo {
    int* p;

    void opAssign(Foo rhs) {
        p = rhs.p;
        (*p)++;
    }
}

unittest {
    immutable a = Foo(new int(3));
    assert(*a.p == 3); // Passes
    Optional!(immutable(Foo)) b;
    b = a;
    assert(*a.p == 3); // Fails
}

There actually is a workaround for this, using destroy() and move() instead of assignment. I'm unsure if there are other corner cases to consider.


--
  Simen

On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:
> Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable.
>
> Optional!(immutable int) a = some(3);
> a = none;
>
> I used to do this via a dynamic array and opAssign would recreate the array
>
> struct Optional(T) {
>   T[] bag;
>   opAssign(T t) {
>     bag = [t]
>   }
> }
>
> But then there were problems with inout, namely:
>
> Error: variable `Optional!(inout(A)).Optional.bag` only parameters or stack based variables can be inout
>
> So I changed it to a stack variable (prefer this anyway, it's not only because of the inout error) but now I'm unsure if I'm violating the type system. Basically I'm now storing T as Unqual!T, but what I'm looking for is a Rebindable implementation that's for value types as well. Is this possible?
>
> Now I do this:
>
> struct Optional(T) {
>   Unqual!T value;
>   opAssign(T t) {
>     value = cast(Unqual!T)(t);
>   }
> }
>
> I put up a PR if anyone wants to see the code. Any pointers, tips would be highly appreciated:
>
> https://github.com/aliak00/optional/pull/13/files#diff-cb543fea6a0b5eeb07b6aac9f068e262
>
> Cheers
> - Ali

Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable

On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote:
> Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable

Allow me to quote from aliak's post:

> what I'm looking for is a Rebindable implementation that's for value types

As can be surmised from the above line, aliak has looked at Rebindable, and it doesn't work with value types.

--
  Simen

On Monday, 26 March 2018 at 10:13:08 UTC, Simen Kjærås wrote:
> On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote:
>> Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable
>
> Allow me to quote from aliak's post:
>
>> what I'm looking for is a Rebindable implementation that's for value types
>
> As can be surmised from the above line, aliak has looked at Rebindable, and it doesn't work with value types.
>
> --
>   Simen

Though Rebindable could be improved to work with value types:

https://github.com/dlang/phobos/pull/6136

On Monday, March 26, 2018 10:13:08 Simen Kjærås via Digitalmars-d-learn wrote:
> On Monday, 26 March 2018 at 09:46:57 UTC, Nicholas Wilson wrote:
> > Have a look at Rebindable: https://dlang.org/phobos/std_typecons.html#rebindable
>
> Allow me to quote from aliak's post:
> > what I'm looking for is a Rebindable implementation that's for value types
>
> As can be surmised from the above line, aliak has looked at Rebindable, and it doesn't work with value types.

It doesn't make sense for it to work with value types. Its entire purpose is
to be able to do the equivalent of const(T)* and immutable(T)* with classes.

If I correctly follow what the OP is trying to do, it's in violation of the type system. You can't cast away const or immutable like that and mutate the object. Honestly, what Rebindable does is pretty questionable as far as the type system goes, but it does what it does by forcing pointer semantics on a class reference, so the point is arguable. However, I think that the reality of the matter is that Rebindable technically breaks the type system. It just happens to do so in a way that always works, and there is no other way to do what it does. But trying to do something like

struct Foo(T)
{
    const T _member;
}

where you cast away const and mutate the member is definitely in violation of the type system and risks serious bugs depending on the optimizations that the compiler chooses to employ - even more so if immutable is used.

- Jonathan M Davis

On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:
> Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable.
>
[snip]

You might look at the source for std.typecons.Nullable. They use an inout constructor.

On Sunday, 25 March 2018 at 23:00:11 UTC, Simen Kjærås wrote:
> On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:
>> struct Optional(T) {
>>   Unqual!T value;
>>   opAssign(T t) {
>>     value = cast(Unqual!T)(t);
>>   }
>> }
>
> Consider this case:
>
> Optional!(immutable int) a = some(3);
> immutable int* p = &a.value;
> a = some(5);

Ahh, bugger.

> As for the problems you've had with inout, I wrote this template a few years back:

This template seems to substitute type qualifiers from the FromType to any inout qualifiers in the ToType yes? I'm not sure how I'd use this actually. I would like to support the inout usecase when a user does

Optional!(inout int) a = 3; // for e.g.

I guess for that template I'd need to have some extra information that tells me what to substitute inout with yeah?

> Of course, if Optional offers no way to get a reference to the wrapped value (say, if a.value is an @property function that doesn't return ref T), then using Unqual internally is safe*.

This thought crossed my mind as well, value should be private anyway, and there's an unwrap function that provides a pointer to the value if it exists, so I wouldn't know how to get around that (return a dynamic array with one or no element that contains a copy and only if it's immutable, else return a pointer? erm ... O_o ) and then I was thinking compiler optimizations may throw in wrench in that if I did find a way around.

> unittest {
>     immutable a = Foo(new int(3));
>     assert(*a.p == 3); // Passes
>     Optional!(immutable(Foo)) b;
>     b = a;
>     assert(*a.p == 3); // Fails
> }
>
> There actually is a workaround for this, using destroy() and move() instead of assignment. I'm unsure if there are other corner cases to consider.

I'm curious what the move/destroy workaround would be?

Cheers,
- Ali

On Monday, 26 March 2018 at 21:17:10 UTC, jmh530 wrote:
> On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:
>> Hi, I have this optional type I'm working on and I've run in to a little snag when it comes to wrapping an immutable. Basically what I want is for an Optional!(immutable T) to still be settable to "some" value or "no" value because the Optional wrapper itself is mutable.
>>
> [snip]
>
> You might look at the source for std.typecons.Nullable. They use an inout constructor.

Unfortunately

Nullable!(inout int) b = 3;

produces that compiler error. This seems more a case on how T is stored than about construction in particular. Was interesting to see a use case for hasElaborateAssign though!

By the by,  how come inout has to be stack based and const/immutable/mutable doesn't? Isn't inout just one of those depending on context?

Cheers,
- Ali