RFC: scope and borrowing

via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 12 01:06:18 PDT 2014


On Thursday, 11 September 2014 at 20:45:09 UTC, Marc Schütz wrote:
> On Thursday, 11 September 2014 at 16:32:54 UTC, Ivan Timokhin 
> wrote:
>> 1. AFAIK, all current D type modifiers can be safely removed 
>> from the topmost level (i.e. it is OK to assign 
>> immutable(int[]) to immutable(int)[]), because they currently 
>> apply to particular variable, so there's no good reason to 
>> impose same restrictions on its copy. Situation seems 
>> different with scope: it is absolutely not safe to cast away 
>> and it applies to a *value*, not a variable holding it.
>
> The types in your example are implicitly convertable, indeed no 
> explicit cast is necessary. This is because when you copy a 
> const value, the result doesn't need to be const. But with 
> scope, it makes sense (and is of course necessary) to keep the 
> ownership. I don't see that as an inconsistency, but as a 
> consequence of the different things const and scope imply: 
> mutability vs. ownership.

I've addressed this in the Wiki now. There were only a few 
changes to be made to move away from type modifiers. I had even 
suggested it as an implementation detail, but didn't think of 
making it part of the specification. Thank you for that insight, 
it makes the proposal more consistent and avoids the troubles 
with the types.

>
>>
>> This is not only inconsistent, but may also cause trouble with 
>> interaction with existing features. For example, what should 
>> be std.traits.Unqual!(scope(int*)) ?
>
> Good question. I would say it needs to keep scope, as it was 
> clearly designed with mutability in mind (although it also 
> removes shared, which is however related to mutability in a 
> way). Ownership is an orthogonal concept to mutability.

After the changes, this is now the case.

>> This is a bit troublesome, because this is how things like 
>> std.range.ElementType work currently, so they may break. For 
>> example,
>> what would be ElementType!ByLineImpl (from the 
>> "scope(const...)" section)?
>
> I see... it can _not_ be:
>
>     scope!(const ByLineImpl!(char, 
> "\n").init)(ByLineImpl!(char, "\n"))
>
> because the init value is copied and thus becomes a temporary. 
> This is ugly. It would however work if ElementType would take 
> an instance instead of a type.

Ditto, this works now. The type is now simply `char[]` (or 
whatever), the owner is tracked separately.


More information about the Digitalmars-d mailing list