[Dlang-internal] DIP1000 discussion and testing

[Mathias Lang via Dlang-internal]

On Monday, 24 October 2016 at 19:30:16 UTC, Walter Bright wrote:
> On 10/24/2016 2:13 AM, Mathias Lang wrote:
>> So it means that the storage class of 'e' changes during 
>> semantic analysis of
>> the function. I don't think that's something we want to ever 
>> do.
>
> Why? D already infers lots of things.

To answer your question: Because it isn't even inference.
The specs explicitly says "Unlike module level declarations, 
declarations within function scope are processed in order." 
(https://dlang.org/spec/function.html)
Changing the storage class of a previous declaration is then 
explicitly breaking that line of the spec, and breaking a key 
assumption the specs / compiler relies on. I pointed that problem 
using delegate, I could have done so using templates, nested 
functions, or whatever part of the language that relies on said 
assumption.

On Monday, 24 October 2016 at 19:32:45 UTC, Walter Bright wrote:
> On 10/24/2016 9:49 AM, Mathias Lang wrote:
>> Why is this necessary / what would be the problem in allowing 
>> it in @system ?
>
> For one thing, it would require all users to learn scope 
> semantics and annotate them correctly. It would be like 
> requiring const correctness.

Users will have to learn `scope` semantic to write `@safe` code.
If one doesn't want to learn `scope` semantics, one just doesn't 
use it, `scope` is opt-in after all.
I fail to see any benefit for someone that doesn't want to learn 
`scope`, and find it extremely confusing for users that want to 
use it but can't make their code `@safe` (because for example, 
they're accepting a delegate which can be @system so they can't 
just wrap code in `@trusted`).