RFC: scope and borrowing

Ivan Timokhin via Digitalmars-d digitalmars-d at puremagic.com
Sat Oct 4 10:01:57 PDT 2014


04.10.2014 17:38, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" пишет:
> On Friday, 3 October 2014 at 19:08:10 UTC, Ivan Timokhin wrote:
>> 29.09.2014 18:17, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>"
>> пишет:
>> ...
>> Now, an idea that I have is that bare scope should be just a syntactic
>> sugar for self-owned scope; i.e., `scope(int*) x;` would be just a
>> short way of writing `scope!x(int*) x;`. This would imply that every
>> scoped variable has its own unique type, which is probably not that
>> terrible, considering that they can't be assigned freely to each other
>> either way. This is also somewhat more natural, because it means that
>> there is no such thing as just "scoped" variable, it is always
>> connected to a particular lifetime.
>
> I've already suggested this as an implementation detail.
>

Sorry then, must have missed it.


 >> ...
> This of course has the unfortunate side effect of incredible template
> bloat: For any distinct passed argument (which in practice means for
> almost every call), we'd get a new template instance. IMO this is not
> acceptable.
>

They could be merged in an executable, but a symbol table would be 
cluttered. That does sound like a major issue.

>>
>> As for passing unscoped strings to findSubstring, I see two alternatives:
>> 1) Declare that all unscoped references are implicitly convertible to
>> scope!GC or something like that (and this conversion is used in such
>> cases). This one is probably better.
>
> OTOH it would preclude automatic demoting of GC allocations to stack
> allocations. And it would marry us to the GC is "default" allocation
> strategy, which we might want to move away from (probably in favor of
> generic allocators changeable at any point in time).
>

It doesn't necessarily have to be GC, just any object that we can safely 
treat as an owner.

>> ...
>
> I think the key is in separating the scope attribute and the owner. The
> former needs to be part of the type, the latter doesn't. In this vein,
> it's probably a good idea to restrict the `scope!owner` syntax to
> function signatures, where it may only refer to other parameters and
> `this`. The use cases for it elsewhere are very marginal (if they exist
> at all).
>
> This naturally makes the return type of `findSubstring()` just
> `scope(string)`; declaring a variable of it simply works:
>
>      typeof(findSubstring("", "")) s = findSubstring("Hello, world",
> "world");
>
> is equivalent to:
>
>      scope(string) s = findSubstring("Hello, world", "world");
>
> This is a valid assignment, and owner propagation would even take care
> of preserving the owners (though only on declaration, but that's natural
> because the owners are only known at the call site):
>
>      string haystack, needle;
>      scope(string) s = findSubstring(haystack, needle);
>      // type of `s` is scope(string), owner is `haystack`
>
> In other words, the type part of `scope!a(T)` is just `scope(T)`, the
> owner is not part of the type and tracked separately.
>

That's ok with me (in fact, it looks very nice), but I think Manu's 
point was that dealing with anything that isn't part of the type is 
troublesome.

> ...


More information about the Digitalmars-d mailing list