RFC: scope and borrowing

[Manu via Digitalmars-d]

On 12 September 2014 18:06, via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

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


I'm not convinced this is a good change.
It sounds like you're just trading one problem with another more sinister
problem...

What happens when a scope() thing finds it's way into generic code? If the
type doesn't carry that information, then you end up in a situation like
ref. Have you ever had to wrestle with ref in generic code?
ref is the biggest disaster zone in D, and I think all it's problems will
translate straight to scope if you do this.


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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140913/fb080410/attachment-0001.html>