[Dlang-internal] DIP1000 discussion and testing

[Mathias Lang via Dlang-internal]

On Monday, 24 October 2016 at 21:30:50 UTC, Walter Bright wrote:
> On 10/24/2016 2:11 PM, Mathias Lang wrote:
>> 1) As highlighted in the previous post, we should not change 
>> the STC / type of a
>> declaration after it is declared. It's a can of worms and will 
>> break in many ways.
>
> The definition of a storage class is a bit fuzzy. 'scope' does 
> not say where the variable is stored - it does not say "put it 
> on the stack", "put it in the code segment", "put it on the 
> heap". It's more of an attribute, just like nothrow, pure, etc.

`scope o = new Object;`
If you prefer to compare it to `nothrow` or `pure`, that's also 
fine by me.
I still don't know of any place where an attribute can be added 
to a pre-existing variable declaration.


> 'scope' is not a type, although it does affect function type 
> signatures the same as @safe, pure, nothrow and @nogc do, as 
> well as affecting covariance/contravariance in an equivalent 
> manner.

The DIP is very clear that `scope` is not a type qualifier.
The parallel with `const` inference was drawn as a reference to 
https://forum.dlang.org/post/nubdqu$v6u$1@digitalmars.com (and 
your later post).
I see both inference as getting in the way of code readability if 
not requested by the user explicitly.


On Monday, 24 October 2016 at 21:40:48 UTC, Walter Bright wrote:
> 
> Please wait until I investigate that one.

Fair enough, then I'll leave the point of adding attributes for 
later.


>> On Monday, 24 October 2016 at 19:32:45 UTC, Walter Bright 
>> wrote:
>>> On 10/24/2016 9:49 AM, Mathias Lang wrote:
>> 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.

Could you explain the value there is in not checking `scope` in 
`@system` ?
Also, how does that value offset the user confusion and possible 
bugs caused by people trying to use `scope` in `@system` code 
without realizing it doesn't do any check ?
Quick note: I notice you said `@system`. The DIP said "only 
checked in @safe code". Will @trusted by checked ?

Also, I don't quite see what @safe has to do with code lifetime, 
or collaboration.