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