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

[d-bugmail at puremagic.com]

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

Stefan Koch <uplink.coder at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uplink.coder at gmail.com

--- Comment #5 from Stefan Koch <uplink.coder at gmail.com> ---
> the reason for which we want cast() and cast(shared) to compile has to do with a DIP in the works on __mutable.

That should have been in the issue description, as it at least gives a
"tangible benefit" for which one may break the language.

> it but it's more difficult to specify and verify that two operations must be done in immediate sequence, as opposed to one operation

That's very true, however in this case it'd be bought by making the semantics
of cast much more complicated. I.E. the complexity of __mutable would be pushed
into cast, considering that people relay on cast to work properly and
intuitively whereas __mutable is not relied upon by anyone; Such changes should
be considered carefully.

> 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.

Also very true!
However taking the address of a value is not allowed to modify it in any way.
Therefore taking the address is at least in first approximation semantically
invariant with regards to the value itself. The address that & yielded is also
required not to change, those facts can be used in the semantic definition of
mutable and will support the desired semantics.

--