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)".
To repeat my statement from the PR:
I would also prefer to avoid the generation of further
functions, because I want to avoid the code bloat.
That's what my suggestion does, too.
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.
