DIP69 - Implement scope for escape proof references

Manu via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 12 00:42:12 PST 2014


On 11 December 2014 at 23:55, via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Thursday, 11 December 2014 at 12:48:05 UTC, 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?
>
>
> This is a point that most people don't seem to understand yet, and which
> wasn't obvious for me either, at the beginning:
>
> * A `ref` parameter means that it cannot escape the function, _except_ by
> return.
> * A `scope ref` parameter means that it cannot escape the function  _ever_,
> not even by return.
> * A `scope ref` return means that it cannot leave the current statement.
>
> Therefore, a `scope ref` return value can be passed on to the next function
> as a `ref` argument. If that function again returns a reference (even if not
> explicitly designated as `scope`), the compiler will treat it as if it were
> `scope ref`.

Ummm. I reckon there's a good reason that people don't seem to
understand this... because it would have difficulty being any more
unintuitive!
It's contrary to the behaviour of basically everything else in D!
const, pure, nothrow, etc... they all work a reliable and consistent way.

Also, I still don't think I get it... a scope-ref return, which has a
restriction as you say, can be subverted by being piped through a
function that receives and returns it as ref?
What is the point?

>> I'm also quite uneasy with the fact that scope would not be transitive
>> as a storage class. What happens when it's applied to a value type,
>> like a struct, that contains some pointers? An adaptation wrapper for
>> a single pointer is super common; ie, a tiny struct passed by value
>> with scope needs to have it's contained pointer receive the scope-ness
>> of the argument.
>
>
> I agree, this is important. In my proposal, this works without transitivity.
> The wrapper stores the pointer as a `scope` member, then by copying the
> wrapper, the pointer gets copied implicitly, to which the normal scope
> restrictions apply (`scope` on members means "will not outlive the
> aggregate"). If it stored it as normal non-scope pointer, it couldn't get
> assigned in the first place. (Additionally, some higher level tricks are
> possible if we allow scope for value types and overloading on scope.)

How can a member be marked scope? Apparently it's a storage class, not
a type constructor... we can only attribute storage classes to
function args/results(?).


More information about the Digitalmars-d mailing list