Jump to page: 1 2 3
Thread overview
[Issue 19754] cast() sometimes yields lvalue, sometimes yields rvalue
Mar 19, 2019
RazvanN
Mar 19, 2019
ag0aep6g
Mar 21, 2019
Dlang Bot
Mar 23, 2019
Mathias LANG
Mar 24, 2019
Stefan Koch
Mar 24, 2019
Mathias LANG
Mar 28, 2019
Dlang Bot
Mar 28, 2019
RazvanN
May 24, 2019
Dlang Bot
May 25, 2019
ag0aep6g
Jun 29, 2019
Walter Bright
Jun 30, 2019
kinke
Jun 30, 2019
ag0aep6g
Jun 30, 2019
kinke
Jul 02, 2019
RazvanN
Jul 02, 2019
Dlang Bot
Jul 02, 2019
Dlang Bot
Jul 26, 2019
Dlang Bot
Jul 29, 2019
Dlang Bot
Jul 29, 2019
kinke
Jul 30, 2019
Dlang Bot
Sep 25
Dlang Bot
Sep 25
kinke
March 19, 2019
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

--
March 19, 2019
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?

--
March 21, 2019
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

--
March 23, 2019
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);
```

--
March 23, 2019
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
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.

--
March 24, 2019
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.

--
March 24, 2019
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`.

--
March 26, 2019
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?

--
March 28, 2019
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

--
« First   ‹ Prev
1 2 3