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