On Monday, 8 December 2014 at 19:44:48 UTC, Walter Bright wrote:
The difference between 'scope ref' and 'ref' parameters is that
the former cannot be returned by reference.
The difference between 'scope ref' and 'ref' function returns
is that the former cannot be saved by the caller.
You can still safely pass the address of a stack variable by
'ref' - it will not escape. Under the current proposal, as now,
you cannot store a ref by ref, and cannot take the address of a
ref variable.
Easier to go straight with pseudo-code:
struct ByLine
{
scope string front();
// ...
}
auto byLine(File file)
{
return ByLine(file);
}
scope /* ref */ string foo(scope /* ref */ string input)
{
return input[1..$];
}
void main()
{
auto r = file.byLine.map!foo;
string s = r.front; // this should not compile
string s = r.front.dup; // this should compile
// how foo signature should look like for this to work?
}
I mean how many C++ type system features in general are
understood my more
than a handful of people on the planet? For me `ref` is
essentially just a
different flavor of `*` - and if the latter can be part of
type, I see no
reasons why former can't
I agree it's a seductively simple idea. The trouble starts
happening when you start when making ref idempotent, when ref
can only be at the 'head' of a data structure, when trying to
do type deduction of a ref type (do you get the ref, or do you
look 'through' the ref?), what happens with overloading, etc.,
and on and on.
But was there any reason why those traits (alien to type
qualifiers) were pursued? What is the problem with `ref` simply
meaning `non-null pointer` and allowing non-idempotent
ref(ref(int))?
