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

https://issues.dlang.org/show_bug.cgi?id=19754 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |razvan.nitu1305@gmail.com Assignee|nobody@puremagic.com |razvan.nitu1305@gmail.com --

https://issues.dlang.org/show_bug.cgi?id=19754 ag0aep6g <ag0aep6g@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ag0aep6g@gmail.com See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=17729 --- Comment #1 from ag0aep6g <ag0aep6g@gmail.com> --- Dupliate of issue 17729? --

https://issues.dlang.org/show_bug.cgi?id=19754 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> --- @RazvanN7 created dlang/dmd pull request #9474 "Fix Issue 19754 - cast() sometimes yields lvalue, sometimes yields rvalue" fixing this issue: - Fix Issue 19754 - cast() sometimes yields lvalue, sometimes yields rvalue https://github.com/dlang/dmd/pull/9474 --

https://issues.dlang.org/show_bug.cgi?id=19754 Mathias LANG <pro.mathias.lang@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pro.mathias.lang@gmail.com --- Comment #3 from Mathias LANG <pro.mathias.lang@gmail.com> --- > So the cast yields an lvalue. Only for shared, and probably because its semantic are not defined. If you replace this shared with `const` or `immutable`, of course this `cast` is rejected, even if the error message is somewhat confusing ("Error: cannot modify constant cast(int)x", instead of mentioning lvalue). > This does not compile claiming that the result of cast is an rvalue. Should pass and use an lvalue. I don't see any reason it should pass. If anything, the first example should be disallowed. What you aim to do can be equally done by taking a pointer to the qualified variable, and casting that pointer. ``` shared int x; auto p = (cast(int*) &x); ``` --

https://issues.dlang.org/show_bug.cgi?id=19754 --- Comment #4 from Andrei Alexandrescu <andrei@erdani.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. 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. --

March 24, 2019

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

Posted by Stefan Koch

Permalink

Stefan Koch

Permalink

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

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

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

--- Comment #5 from Stefan Koch <uplink.coder@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.

--

https://issues.dlang.org/show_bug.cgi?id=19754 --- Comment #6 from Andrei Alexandrescu <andrei@erdani.com> --- >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. This is nonsense, sigh. Can't even start to debate... There's no complexity tossed around? What's proper and intuitive and what isn't? Applied to primitive types, cast() and cast(qualifier) are currently meaningless. immutable int a; auto b = cast() a; auto c = int(a); assert(is(typeof(b) == typeof(c))); That cast didn't really cast anything because the same code can be written without. Same goes the other way: int a; auto b = cast(immutable) a; immutable c = a; assert(is(typeof(b) == typeof(c))); Again, a nominal cast that really doesn't cast. --

https://issues.dlang.org/show_bug.cgi?id=19754 --- Comment #7 from Mathias LANG <pro.mathias.lang@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`. --

https://issues.dlang.org/show_bug.cgi?id=19754 --- Comment #8 from Andrei Alexandrescu <andrei@erdani.com> --- It seems the main anomaly is that cast() yields (sometimes...) an lvalue for shared data. Razvan, can you investigate if code would break if we forced cast() on shared data to always return an rvalue? --

https://issues.dlang.org/show_bug.cgi?id=19754 --- Comment #9 from Dlang Bot <dlang-bot@dlang.rocks> --- @RazvanN7 created dlang/dmd pull request #9505 "Fix Issue 19754 - cast() sometimes yields lvalue, sometimes yields rvalue" fixing this issue: - Fix Issue 19754 - cast() sometimes yields lvalue, sometimes yields rvalue https://github.com/dlang/dmd/pull/9505 --

Forums