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.
