DIP69 - Implement scope for escape proof references
Dicebot via Digitalmars-d
digitalmars-d at puremagic.com
Mon Dec 8 12:54:52 PST 2014
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))?
More information about the Digitalmars-d
mailing list