Dlist and dip1000 challenge

[Steven Schveighoffer]

On 10/23/18 2:43 PM, Stanislav Blinov wrote:
> 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?

This is where I think there is going to be a problem. scope shouldn't be 
transitive, you can easily have a pointer allocated on the stack point 
to heap data. What is the type that results from taking the address of 
the pointer? It *should* be a pointer to a scoped pointer that points to 
NON-SCOPE data.

It may be an issue of expressability.

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

Yes, I believe the compiler inferring scope can do some things that 
syntax cannot. I think that might be where the issue is, but it's really 
hard to figure out.

-Steve