rval->ref const(T), implicit conversions

[bitwise via Digitalmars-d]

On Monday, 18 January 2016 at 21:39:09 UTC, Anon wrote:
> On Monday, 18 January 2016 at 19:32:19 UTC, bitwise wrote:
>> struct S;
>>
>> void func(ref S s);
>> func(S());   // FINE
>>
>> void func(ref S s) @safe;
>> func(S());   // ERROR
>
> Isn't that backwards? I mean, @safe functions can't escape 
> their parameters, so whether or not it is a temporary shouldn't 
> matter to a @safe function. Meanwhile, non- at safe *can* escape 
> parameters, and would fail or at least lead to problems if it 
> tried to escape a ref to a temporary.
>
> On the other hand, banning @safe code from passing a temporary 
> as a ref parameter, while allowing it in non- at safe code makes a 
> bit more sense to me, but seems less desirable.

It turns out, you're right, but this only makes arguments against 
passing rvalues to ref params even _less_ valid.

You could simply allow rvalue->ref implicit instantiation right 
now, and @safe code would still be @safe, and unsafe code would 
be more convenient.

@safety seems like a very specific concern. Many people just 
won't need that kind of guarantee. Some will be perfectly happy 
ensuring the safety of their own code, while others simply won't 
care if their code is totally safe because they're writing low 
risk or very simple software.

     Bit