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.
