[Dlang-internal] DIP1000 discussion and testing

[Walter Bright via Dlang-internal]

On 10/24/2016 2:02 PM, Mathias Lang wrote:
> 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 don't believe it breaks anything the language 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.

Please wait until I investigate that one.


> 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`,

Writing @system code can be done without paying attention to that stuff, and 
there is value in that. @safe code comes into play when writing larger scale, 
longer lived (!) code, and code that is worked on by a team.


> 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`).

That's the reason for inference. (I'd also like to do inference for 'const'. 
Inference of pure, nothrow, etc., has been very successful, and I don't see any 
fundamental issue with taking it further.)