The next iteration of scope

Zach the Mystic via Digitalmars-d digitalmars-d at
Sun Mar 15 21:00:49 PDT 2015

On Sunday, 15 March 2015 at 14:10:02 UTC, Marc Sch├╝tz wrote:
> Here's the new version of my scope proposal:
> It's still missing real-life examples, a section on the 
> implementation, and a more formal specification, as well as a 
> discussion of backwards compatibility. But I thought I'd show 
> what I have, so that it can be discussed early on.
> I hope it will be more digestible for Walter & Andrei. It's 
> more or less an extended version of DIP25, and avoids the need 
> for most explicit annotations.

It's great to see your design evolving like this. BIG plus for 
`scope` by default in @safe code -- this makes the proposal much 
more attractive than the alternative.

"Functions and methods can be overloaded on scope. This allows 
efficient passing of RC wrappers for instance..."

How does the compiler figure out which of the variables it's 
passing to the parameters are `scope` or not? Does the caller try 
the scoped overloads first by default, and only if there's an 
error tries the non-scoped overloads? If so, what causes the 

"To specify that the value is returned through another parameter, 
the return!ident syntax can be used...

struct RC(T) if(is(T == class)) {
     scope T payload;
     T borrow() return {    // `return` applies to `this`
         return payload;

The example contains no use of `return!ident`.

Also, what exactly does the `scope` on T payload get you? Is it 
just a more specific version of `return` on the this parameter, 
i.e. `return this.payload`? Why would you need that specificity? 
What is the dangerous operation it is intended to prevent?

More information about the Digitalmars-d mailing list