Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Andrei Alexandrescu via Digitalmars-d]

On 10/20/2016 06:23 AM, Ethan Watson wrote:
> On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:
>> Better:
>>
>>    void f(ref Vector v);
>>    void f(Vector v) { f(v); }
>>
>>    f(Vector(10,20,30));
>
> Suitable enough for simple functions. But beyond that becomes
> maintenance hell.

I agree this workaround has a combinatorial problem.

Again, lest this got lost: I think a solid DIP addressing the problem 
would have a good chance to get traction. We are in a better place than 
we used to with handling ref, and also with the general understanding of 
the general matter and how it was problematic for C++.

I'm thinking a DIP would work well around the following lines:

* Explain the problem with well-motivated examples.

* Related work and workarounds, most notably "auto ref" in templates. 
Explain how "auto ref" is insufficient. Explain how workarounds are 
insufficient.

* Propose a semantics that would address the problem. By far the 
preferred way is by means of a lowering to existing language. The 
obvious lowering is to have the compiler introduce "auto" variables 
prior to the call, as follows:

In the call fun(e1, e2), if e1 and e2 are rvalues and fun specifies it 
accepts an rvalue by reference for both parameters, the lowering is:

fun(e1, e2)

=>

{ auto __1 = e1, __2 = e2; return fun(__1, __2); }()

There are potential issues with fun returning ref, which the DIP should 
address.

* Propose an annotation to indicate the function allows rvalues. What 
comes to mind:

(a) Expand the use of "auto ref" to nontemplates. The common objection 
to this is we'd have the same syntax express subtly different semantics 
(for templates there are two distinct functions generated, and inside 
the template it is possible to distinguish between the two). The DIP 
should address this objection.

(b) Use an attribute, e.g. void fun(@rvalue ref Vector);

* Discuss how the annotation affects function signature and mangling 
(not sure but probably there should be no effect).

* Sketch the changes to the language definitions.



Thanks,

Andrei