I close BIP27. I won't be pursuing BIPs anymore

[Jacob via Digitalmars-d]

On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu 
wrote:
> On 10/18/2016 04:15 PM, Atila Neves wrote:
>>
>> I think I get it; I'm just not sure given the comments that 
>> pop up in
>> the forum. Isn't one of the main reasons distinguishing 
>> between these two?
>>
>> void fun(ref const Foo);
>> void fun(Foo);
>>
>> If they can't be distinguished, you don't get move semantics 
>> "for free".
>
> That's right, thanks Atila. -- Andreu

Actually thinking it over some more, you would be able to 
distinguish it. You would simply treat func(Foo) to be the 
equivalent of func(Foo&&) in C++.

void func(ref const Foo);
void func(Foo);

enum ctfeFoo = Foo();

func(ctfeFoo); // calls func(ref const Foo);
                // zero reason to do a move as enum's can't house 
runtime values

const Foo foo;

func(foo); // calls func(ref const Foo);

func(Foo()); // calls func(Foo)
              // no ambiguity, same reason there isn't one for 
C++'s &&
              // Foo() is modifiable temporary

import std.algorithms.mutation : move;

Foo rfoo;
func(move(rfoo)); // calls func(Foo)


So now you would be able to define a single function to take both 
rvalues and lvalues.