http://wiki.dlang.org/DIP25

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 30 14:26:47 PST 2014


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




More information about the Digitalmars-d mailing list