auto ref is on the docket

[kinke via Digitalmars-d]

On Monday, 22 June 2015 at 16:54:50 UTC, Marc Schütz wrote:
> On Monday, 22 June 2015 at 16:10:10 UTC, Namespace wrote:
>> Rather than raising the matter of scope again and again, we 
>> should be thankful that a solution for this nasty problem is 
>> accepted and could be merged.
>
> I disagree strongly with this. A bad solution is worse than no 
> solution.
>
>> How scope and escape analysis could do a better job is unclear 
>> and if you want to solve the problem this way you will wait a 
>> very long time.
>
> Not at all. `auto ref` without a working `scope` implementation 
> is unsafe. If that is acceptable for now, then it should be 
> just as acceptable to already use `scope ref` as a syntax for 
> the same semantics, even if the required escape-proofing of 
> `scope` is not yet implemented.
>
> If/when we will finally get a working `scope`, using those 
> functions will then be actually verified by the compiler. In 
> the meantime, the `scope` keyword will at least express the 
> intention to the caller and will serve as a reminder to the 
> callee's author.
>
> In contrast, with `auto ref` accepting rvalues, we will have 
> the same keywords `auto ref` mean two very different things for 
> templates and non-templates, we still won't have a way to write 
> rvalue-ref-accepting template functions, and when we will 
> finally get `scope`, `auto ref` will be a pointless alternative 
> syntax for `scope ref` that will have to be kept around forever.
>
>> So please let us concentrate and discuss how we could solve 
>> this problem with auto ref. :)
>
> Use `scope ref` instead of `auto ref` now, and just ignore that 
> it's unsafe for the moment. Your PR will become even shorter 
> with it, because you no longer need `STCrvref`. Conceptually, 
> just do "#define STCrvref (STCref | STCscope)".

I definitely see your point and very much agree!

>> I like the way of the current implementation, because it is 
>> following the way C++ does and will be understandable for 
>> every person which comes from C++.
>
> With the difference that C++ requires const-ness.

Yep, so `in ref T` translating to `scope const ref T` would be 
D's convenient and safe counterpart to C++' `const T&` 
parameters, for their main use case: passing pure-input arguments 
of types which are or may be costly to copy (post-blit ctor, 
dtor, or simply big). I explicitly mention 'may be' here because 
in templates one often doesn't know (containers...).

As I have already pointed out in another thread, I'd go one step 
further and propose an extremely convenient `in T` for this very 
common use case:

* The argument is passed by value (`const T`) if the compiler 
assumes moving/copying is more efficient than passing a reference 
(with its indirection on the callee side) for the particular 
target environment (hardware, ABI), e.g., for plain-old-datatypes 
T fitting into 1-2 registers, and Object references obviously.
* Otherwise, the argument is passed by-ref (`in ref T`). As `in 
T` doesn't mention any ref at all, it's clear that the hidden 
reference cannot escape.

Let me give you an example. The Win64 ABI only allows passing POD 
types <= 64 bit by value (exception: vector/SSE types). All other 
types need to be passed by ref, which means that D's otherwise 
cool in-place construction of arguments on the callee's function 
parameters stack isn't possible. The current `auto ref` 
implementation for templates is in vain on Win64 for these 
byref-types, as the ABI forces both versions to take the argument 
byref anyway.

I'm pretty sure I could live without an `auto ref` for templates 
once I can use `in T` for all my pure-input parameters. If the 
function may change the argument, I'd go with `scope ref T`, 
accepting rvalues too. If the function may even let the argument 
escape, it'll have to be `ref T` or `const/immutable ref T`. And 
if I just want to mutate the parameter inside my function, but 
not touch the argument, it'd be `T`. I can't think of any other 
use cases for function parameters atm.