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