DMD Symbol Reference Analysis Pass

[via Digitalmars-d]

On Tuesday, 26 May 2015 at 21:22:38 UTC, Per Nordlöw wrote:
> No, DMD cannot currently handle scope on foreach elements. It 
> errors as
>
>      Error: basic type expected, not scope
>

Quite possible, didn't test it. Anyway, my point was that it 
simply isn't necessary to ever mark a local variable as `scope`. 
The compiler sees all local variables and can figure things out 
by itself. It only needs help in function signatures, in the form 
of explicit `scope` and `return` annotations.

>> example, it would figure out that you're assigning a reference 
>> to a value with shorter lifetime (i.e. the slice to the 
>> buffer) to a value with longer lifetime (saved_line), which it 
>> would disallow. (Btw, I don't think to!string is enough, 
>> because it is probably a no-op in this case: string -> string).
>
> No to!string is not a no-op in this case. It allocates but it 
> needs to create an immutable char array that is: char[] -> 
> string

I see, File.byLine returns a range of char[], I thought it 
returned a string range. Then you're of course right.

>
>> However, byLine has another problem, which boils down to the 
>> same cause as the problem with RCArray, namely that the 
>> content of the buffer is reused in each iteration.
>
> This is what I meant with volatile. Is there a better word for 
> this?

I guess it's fine, and now I remember again that ranges with this 
property have been called "volatile ranges".

>
>> the "owner" can be modified while references to it exist. For 
>> byLine, this is not a safety violation, but for RCArray it is. 
>> A solution applicable to both is to detect this and then 
>> either treat such a situation as @system, or make the owner 
>> `const` as long as the references are alive.
>
> AFAIK: Allowing scope in foreach would solve this problem in my 
> case.

See above. Conceptually, you can of course treat it as if it were 
marked with `scope`, but an actual annotation should not be 
necessary.