[Issue 19754] cast() sometimes yields lvalue, sometimes yields rvalue

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19754

--- Comment #7 from Mathias LANG <pro.mathias.lang at gmail.com> ---
> Mathias, the reason for which we want cast() and cast(shared) to compile has to do with a DIP in the works on __mutable. That would require inserting a manual cast (either cast() or cast(shared)) when the compiler is unable to assess whether the data originated as unqualified or immutable.

Its relationship with `__mutable` wasn't mentioned anywhere in the original
post, although it wasn't too hard to guess to be fair.
OP describes cast as supposed to return lvalues, which is the opposite of how
the language work, except for an unfinished type constructor. Even if it's a
convenient property for your current focus, it is the oddity here, not the
norm.

> Yes, we could take the address and cast it but it's more difficult to specify and verify that two operations must be done in immediate sequence, as opposed to one operation. I think there may be a few cases in which two successive operations are semantically checked together but wouldn't want to add to those.

The point is that there is no bug here. `cast` returning an rvalue is very
clearly intended. Changing this should go through the proper process, so that
the benefit and impact of the change is considered from the PoV of the whole
language, not just `__mutable`.

--