[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure (page 2)

https://issues.dlang.org/show_bug.cgi?id=16037 Mathias Lang <mathias.lang@sociomantic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Mathias Lang <mathias.lang@sociomantic.com> --- This is wrong. Gratuitously breaking code is not okay, especially when this code could be working correctly, even if some safety checks were not performed. This should not be considered in the context of a single codebase, but in the context of the whole ecosystem: if you break code that is working in a library that many depends on, a user won't care if the language is better as [s]he is not able to use it. I raised an objection on the PR about it being an reject-valid, but Walter rightly pointed out that the reasoning is the same: https://github.com/dlang/dmd/pull/7981#issuecomment-370570068 --

https://issues.dlang.org/show_bug.cgi?id=16037 --- Comment #7 from anonymous4 <dfj1esp02@sneakemail.com> --- Clarify how breaking invalid code is gratuitous. If the code is correct it won't be broken. --

https://issues.dlang.org/show_bug.cgi?id=16037 --- Comment #8 from anonymous4 <dfj1esp02@sneakemail.com> --- Anyway, if `in` loses scope semantics, it will break @nogc code like in the example above, you can't eliminate breakage completely here. --

March 20, 2018

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

Posted by Mathias Lang

Permalink

Mathias Lang

Permalink

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

--- Comment #9 from Mathias Lang <mathias.lang@sociomantic.com> ---
@anonymous4: For starter, DIP1000 fixes only apply to @safe function ATM. While it's a decision I don't agree with personally, it's the path that was chosen and changing it would need to happen at a higher level than this issue.

Second, w.r.t to breaking "invalid" code, often the idea of unverified / unverifiable code and buggy code get mixed up.

If you have the following code:
```
ubyte foo (uint i)
{
    if (i <= ubyte.max)
        return i;
    return 0;
}
```

While this code is obviously correct, it does not currently compile. That what I call unverified code. You know it's correct, and a smarter compiler would know it's correct, but it's not currently allowed.

Now there is some code that is unverifiable. Let's say:
```
ubyte foo (uint i)
{
    return i;
}
```
This is clearly wrong, you'd say. And you'll be right. Unless:
- `foo` is never called
- `foo` is only called with a value 0 <= x <= ubyte.max
- values over `ubyte.max` would be ignored anyway (e.g. for a bitmask)
Either way this is a bug in the compiler we need to fix, but it's not actually
a bug in the user code. Forbidding it would be an annoyance for a user.

Of course, one could argue that the annoyance is minor for the user, and the fix trivial. But more often than not, users don't have control about the integrality of the code base. Users have dependencies to libraries, which themselves might have dependencies to other libraries. The web can get wide pretty quickly, and suddenly your user is stuck in a situation where he has to spend an unreasonable amount of time to change code that was not buggy to begin with.

So I strongly oppose gratuitous breakage of code (breakage with does not come with a deprecation) because it makes the ecosystem unstable, always moving, and hard to use.

--

https://issues.dlang.org/show_bug.cgi?id=16037 --- Comment #10 from anonymous4 <dfj1esp02@sneakemail.com> --- (In reply to Mathias Lang from comment #9) > The web can get wide > pretty quickly, and suddenly your user is stuck in a situation where he has > to spend an unreasonable amount of time to change code that was not buggy to > begin with. Correct code won't be broken by this optimization. --

https://issues.dlang.org/show_bug.cgi?id=16037 --- Comment #11 from anonymous4 <dfj1esp02@sneakemail.com> --- (In reply to Mathias Lang from comment #9) > So I strongly oppose gratuitous breakage of code (breakage with does not > come with a deprecation) You want usage of `scope` storage class be reported as deprecated? Would -transition=scope flag be good enough for it? --

https://issues.dlang.org/show_bug.cgi?id=16037 anonymous4 <dfj1esp02@sneakemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |betterC Status|RESOLVED |REOPENED See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=18949 Resolution|FIXED |--- --- Comment #12 from anonymous4 <dfj1esp02@sneakemail.com> --- Another use case is betterC, which is unlikely to be safe. --

https://issues.dlang.org/show_bug.cgi?id=16037 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |razvan.nitu1305@gmail.com Resolution|--- |FIXED --- Comment #14 from RazvanN <razvan.nitu1305@gmail.com> --- This issue has been fixed: https://github.com/dlang/dmd/pull/7981 --

Forums