On 12/29/14 5:02 PM, Manu via Digitalmars-d wrote:
On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On 12/29/14 2:58 AM, John Colvin wrote:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if we can avoid it, and
generally we want to achieve what we need to achieve with minimum
aggravation. Instead please focus on what you're trying to accomplish,
not on whether an artifact is a type qualifier or a storage class.
Thanks.
Andrei
But (one of) his point(s) is that the choice between type qualifier and
storage class directly impacts his work. Why shouldn't a user express
such a point?
Making that point is fine so long as the costs are discussed alongside with
the applicability to one particular task. -- Andrei
It's not one particular task. It is the common theme for almost all
ref related problems (other than rvalue->ref, which is just
arbitrarily rejected currently).
Not arbitrary at all. The problem with binding rvalues to ref is that
subsequently the ref may escape the scope. DIP25 would not have been
possible if rvalues bound to ref.
I'm trying to raise that topic for discussions, but nobody wants to
talk about it, and would rather focus on patches instead.
I don't know exactly where ref as type constructor would lead.
That would imply you'd have more restraint in pushing it.
Sure,
it would be complex no doubt, but not necessarily any more or less
complex than the awkward network of edge cases we're trying to deal
with in these discussions currently.
My feeling is, all these discussions are essentially arguing an
*extremely* complex suite of language patches. I'm interested in
considering the root problem for contrast... I think we'd find
ourselves in a position with a lot less edges as result.
I think you are wrong about this.
Andrei
