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
