Dlist and dip1000 challenge

Stanislav Blinov stanislav.blinov at gmail.com
Tue Oct 23 18:43:24 UTC 2018


On Tuesday, 23 October 2018 at 17:48:23 UTC, Steven Schveighoffer 
wrote:

> Except that there should be no pointers to scope data here -- 
> the only thing that is scope really is the string[] pointer. 
> When you extract a string from that, it shouldn't be scope.
>
> If it is being inferred scope, how does one have a scope array 
> of non-scope pointers?
>

I *think* there's a bug with the implementation of DIP1000:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#aggregates

- Lifetimes of built-in dynamically-sized slices T[] are analyzed 
as structs with two fields, one of type T* and the other of type 
size_t.

- For struct members of aggregate type, decomposition may 
continue transitively.

So, if "decomposition may continue transitively", it looks as if 
there's no tail-scope for arrays, but then shouldn't it follow 
that for

void foo(scope string[] args...);

it should transitively slap `scope` into the immutable(char)* of 
each argument?

However,

string[] escape;

// compiles, i.e. the behavior you essentially want
void foo(scope string[] args...) {
     foreach (s; args) escape ~= s;
}

// doesn't compile, i.e. the behavior you essentially get
void bar(scope string arg) {
     escape ~= s;
}

...and yet, in your code example the compiler behaves as if each 
string was indeed `scope`.


More information about the Digitalmars-d mailing list