DIP69 - Implement scope for escape proof references

Manu via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 12 04:19:39 PST 2014


On 12 December 2014 at 07:41, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 12/11/2014 4:47 AM, Manu via Digitalmars-d wrote:
>>
>> On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On 12/7/2014 6:12 AM, Dicebot wrote:
>>>>
>>>>
>>>> But from existing cases it doesn't seem working good enough. For
>>>> example,
>>>> not
>>>> being able to represent idiom of `scope ref int foo(scope ref int x) {
>>>> return x;
>>>> }` seems very limiting.
>>>
>>>
>>>
>>>    scope ref int foo(ref int x);
>>>
>>> will do it.
>>
>>
>> Will it? It looks like foo can't be called with scope data?
>
>
> Yes, it can be.
>
>
>> I don't have the perfect proposal, but I feel very strongly about 2
>> things:
>> 1. It must not be a storage class; the concept was a disaster with
>> ref, and I struggle with this more frequently than any other 'feature'
>> in D.
>
>
> I simply do not understand why distinguishing beteen ref and not-ref is a
> cornerstone of everything you do.

I've said so many times, it's the single greatest regular frustration
I encounter, by far.
That is of course a relative measure. It's not the 'cornerstone of
everything I do'; I don't start discussions about things that are not
broken and otherwise painless.
It is the thing that is *the most broken*, and leads to the most edge
cases, general bloat, and text mixins.
It comes up the most frequently, and by that metric alone, I consider
it highest priority on my list.

I've also said many times before, it possibly stems from the fact that
one of the key cornerstones of almost everything I do in D is interact
with other languages.
This is a practical reality, I can't write all my code in D, and have
mountains of existing code to interact with.
Boilerplate is the result. D has powerful systems to automate
boilerplate, like a carrot dangling right in front of my face, but
it's almost always thwarted by ref, and almost exclusively so.

My recent work updating LuaD to support all the features I required
wasted about 80% of my time dealing with ref issues.
In my past C++ bindings solutions, much code, which was otherwise
simple, readable, and elegant, turned into a mess of text mixins,
almost exclusively because ref is broken.


>> 2. I feel it's a big mistake to separate it from the type system,
>> which I think most agree, is D's greatest asset by far. Manipulating
>> types is simple and convenient using the type system, and I think
>> manipulating scope will be just as important as any other attribute as
>> soon as even slightly complex use cases begin to arise.
>
>
> Consider a ref counted type, RC!T. If scope were transitive, then you could
> not have, say, a tree where the edges were RC!T. I.e., the payload of an RC
> type should not be forced to be scope.

I'm not sure I quite visualise this correctly...

It sounds like you're talking about the same problem where people
complain with respect to 'const' and you happily tell them to stop
whingeing and deal with it?
(FWIW, I think you made the right call on const. It's never caused me
any hair loss.)

So you're saying that a pointer itself shouldn't be able to escape a
call tree, but the thing it points to should be able to escape just
fine?
It feels like that kinda defeats the purpose... or at least makes the
concept about as reliable as 'const' is in C++.

I guess you're seeing a situation where 'scope' is almost exclusively
useful as a mechanism to tell the RC that it doesn't need to worry
about ref-fiddling, and the thing we're passing isn't interested in
scope restrictions at any level other than that RC optimisation?
I guess I can see your angle... but my reaction is if that's all you
are concerned about, maybe scope is the wrong tool for eliding ref
fiddling in that case :/

I can see how you arrived at the opinion from your other comment
(wherever it was) that you are kinda likening this whole problem to
the RC case, if that's how you're looking at it.
It sounds like what you want is something like head-scope, in the same
way that people often want head-const?


More information about the Digitalmars-d mailing list