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