DIP69 - Implement scope for escape proof references

Manu via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 11 04:47:55 PST 2014


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?


>> I also don't consider `ref` design as a storage class any kind of success
>> at all
>> and generally agree with Manu on this topic. At the same time alternative
>> proposals that make it a qualifier (like Marc did) do impact existing
>> language
>> much more and this no small concern.
>
>
> My experience with C++ ref as type qualifier is very, very bad. It's a
> special case EVERYWHERE. Doing type deduction with it is an exercise in a
> completely baffling set of rules and a different rule for every occasion -
> Scott Meyers has a great piece on this.
>
> There are probably only a handful of people on the planet who actually
> understand C++ ref. I wished very hard to avoid that with D ref.

I do completely sympathise with you on this point. I understand where
you were coming from on 'ref', and I do applaud the effort. Nobody
said that ref should be just the same as C++, but I am saying that the
D solution is not a success.
I'm all about a ref that improves on C++, but I don't think that's
what we have. We have something that's just complex and unwieldy in a
different (and for my money, even more frustrating) way.

I'm just saying, don't repeat that mistake with scope! There must be
another way...

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


More information about the Digitalmars-d mailing list