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

[d-bugmail at puremagic.com]

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

--- Comment #9 from Mathias Lang <mathias.lang at 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.

--