DIP69 - Implement scope for escape proof references

[Walter Bright via Digitalmars-d]

On 12/6/2014 1:50 AM, Manu via Digitalmars-d wrote:
>> I didn't fully understand Manu's issue, but it was about 'ref' not being
>> inferred by template type deduction. I didn't understand why 'auto ref' did
>> not work for him. I got the impression that he was trying to program in D
>> the same way he'd do things in C++, and that's where the trouble came in.
> NO!!
> I barely program C++ at all! I basically write C code with 'enum' and
> 'class'. NEVER 'template', and very rarely 'virtual'.
> Your impression is dead wrong.

I apologize for misunderstanding you.


> It's exactly as Marc says, we have the best tools for dealing with
> types of any language I know, and practically none for dealing with
> 'storage class'.
> In my use of meta in D, 'ref' is the single greatest cause of
> complexity, code bloat, duplication, and text mixins. I've been
> banging on about this for years!
>
> I've been over it so many times.
> I'll start over if there is actually some possibility I can convince
> you? Is there?

I know there's no easy way to derive a storage class from an expression. The 
difficulty in my understanding is why this is a great cause of problems for you 
in particular (and by implication not for others). There's something about the 
way you write code that's different.


> I've lost faith that I am able to have any meaningful impact on issues
> that matter to me, and I'm fairly sure at this point that my
> compounded resentment and frustration actually discredit my cause, and
> certainly, my quality of debate.

This is incorrect, you had enormous influence over the vector type in D! And I 
wish you had more.


> There has been a couple of instances where the situation has been
> appropriate that I've tried to make use of auto ref, but in each case,
> the semantics have never been what I want.

I don't really know what you want. Well, perhaps a better statement is 'why', 
not what.


> ref is a bad design. C++'s design isn't fantastic, and I appreciate
> that D made effort to improve on it, but we need to recognise when the
> experiment was a failure. D's design is terrible; it's basically
> orthogonal to the rest of the language. It's created way more
> complicated edge cases for me than C++ references ever have. Anyone
> who says otherwise obviously hasn't really used it much!
> Don't double down on that mistake with scope.

Why does your code need to care so much about to ref or not to ref? That's the 
central point here, I think.


> My intended reply to this post was to ask you to justify making it a
> storage class, and why the design fails as a type constructor?
> Can we explore that direction to it's point of failure?
>
> As a storage class, it runs the risk of doubling out existing bloat
> caused by ref. As a type constructor, I see no disadvantages.
> It even addresses some of the awkward problems right at the face of
> storage classes, like how/where the attributes actually apply. Type
> constructors use parens; ie, const(T), and scope(T) would make that
> matter a lot  more clear.
>
> Apart from the storage class issue, it looks okay, but it gives me the
> feeling that it kinda stops short.
> Marc's proposal addressed more issues. I feel this proposal will
> result in more edge cases than Marc's proposal.
> The major edge case that I imagine is that since scope return values
> can't be assigned to scope local's, that will result in some awkward
> meta, requiring yet more special cases. I think Mark's proposal may be
> a lot more relaxed in that way.

The disadvantages of making it a type qualifier are:

1. far more complexity. Type constructors interact with everything, often in 
unanticipated ways. We spent *years* working out issues with the 'const' type 
qualifier, and are still doing so. Kenji just fixed another one.

2. we are never going to get users to use 'scope' qualifiers pervasively. It's 
been a long struggle to get 'const' used.

3. we added 'inout' as a type qualifier to avoid code duplication engendered by 
'const'. It hurts my brain to even think about how that might interact with 
'scope' qualifiers.

Yes, I agree unequivocably, that 'scope' as a type qualifier is more expressive 
and more powerful than as a storage class. Multiple inheritance is also more 
expressive and more powerful than single inheritance. But many times, more power 
perhaps isn't better than redoing the program design to use something simpler 
and less complex.