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

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #14 from RazvanN  ---
This issue has been fixed: https://github.com/dlang/dmd/pull/7981

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #13 from Walter Bright  ---
I'm not sure why this was reopened.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18788

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  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  ---
Another use case is betterC, which is unlikely to be safe.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #11 from anonymous4  ---
(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?

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #10 from anonymous4  ---
(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.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #9 from Mathias Lang  ---
@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.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from anonymous4  ---
Anyway, if `in` loses scope semantics, it will break @nogc code like in the
example above, you can't eliminate breakage completely here.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from anonymous4  ---
Clarify how breaking invalid code is gratuitous. If the code is correct it
won't be broken.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Mathias Lang  ---
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

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords|safe|
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from anonymous4  ---
Should work the same is @system code; "don't break working code" only applies
to valid code; if code advertizes scoping, but doesn't respect it, it's invalid
and there shouldn't be any guarantee for it to work.

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/4b93ddef41508453c6e83b11e62f97ae870c8c98
fix Issue 16037 - assigning delegate to a scope variable shouldn't allocate
closure

https://github.com/dlang/dmd/commit/81283694ce96174fe854b975d68384da7cbc66b7
Merge pull request #7981 from WalterBright/fix16037

fix Issue 16037 - assigning delegate to a scope variable shouldn't al…

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7981

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||safe

--

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

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords|safe|performance
Summary|Closure allocation despite  |assigning delegate to a
   |scope variable for ternary  |scope variable shouldn't
   |operator / CondExp  |allocate closure
   Severity|major   |enhancement

--- Comment #2 from anonymous4  ---
I've run into this myself :)
Simpler example:
---
void f() //@nogc
{
int a;
void g(){ a=1; }
scope h=
h();
}
---
This shouldn't allocate closure because the delegate is assigned to a scope
variable.

--