http://wiki.dlang.org/DIP25

[Manu via Digitalmars-d]

On 31 December 2014 at 08:26, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

However this code is perfectly legal:

void mayEscape(ref int x); // <-- may escape this ref arg

void t()
{
  int onStack = 1;
  mayEscape(onStack); // <- perfectly legal, and equally unsafe
}


While that code is legal, the rejection of rvalue->ref is absolutely arbitrary.
The 'workaround' for not allowing rvalue->ref is to simply assign it
to a stack local with a stupid name (eg: t1, t2, etc) on the preceding
line.
That workaround appears in *every* instance that rvalue->ref would be
used, making code messy and more difficult to maintain.

Obviously, I'm all for scope, and lifetimes and all that to make this
stuff properly safe. But the current situation is that we are
inconvenienced by an arbitrary decision.

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

Why? I think there's a serious danger here.
Precedent would lead to me to fear that the sort of reasoning that
lead to 'auto ref' may prevail here again.

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

In what way?
I don't see why exploring a more fundamental solution is absolutely
off the table.