Following work on typechecking synchronized methods, Walter and I were discussing about managing escaping references to objects that wouldn't actually agree to escaping. The problem is that today a value has no idea that its address is being taken, so it has no saying in that.

To compensate for that, my idea was to allow @disable on opUnary!"&". Walter suggested allowing "scope" as a property of a struct:

scope struct Transitory
{
    ...
}

A scope struct cannot have its address taken. You can take addresses of its members (access permitting), but you can't take the address of any other struct that has at least one scope struct as a direct member. For example:

struct A
{
    int x;
    Transitory tr;
}

A will also be scope. So scope has this funny way of propagating outwards, as opposed to qualifiers, which propagate inwards.

This is as much as we have in terms of a design right now, so definitely it stands some more fleshing out. If gotten right, scope should allow defining a number of useful idioms, such as pass-down values, unique/lent objects, and the such.

Working against escapes has long been a problem, and with scope we're hoping to strike a balance between useful and simple.

Please share any thoughts you might have.


Andrei

Andrei Alexandrescu wrote:
> Following work on typechecking synchronized methods, Walter and I were discussing about managing escaping references to objects that wouldn't actually agree to escaping. The problem is that today a value has no idea that its address is being taken, so it has no saying in that.
> 
> To compensate for that, my idea was to allow @disable on opUnary!"&". Walter suggested allowing "scope" as a property of a struct:
> 
> scope struct Transitory
> {
>     ...
> }
> 
> A scope struct cannot have its address taken. You can take addresses of its members (access permitting), but you can't take the address of any other struct that has at least one scope struct as a direct member. For example:
> 
> struct A
> {
>     int x;
>     Transitory tr;
> }
> 
> A will also be scope. So scope has this funny way of propagating outwards, as opposed to qualifiers, which propagate inwards.

Though the feature seems useful, I worry about the asymmetry with scope classes.  I think it will be very confusing to new D programmers that a scope class and a scope struct have very little to do with each other.

  - You can't have globals, statics, fields, or enums that
    are scope classes, but it seems they can be scope structs.
    (Hence, there can be no outward propagation of the scope
    class qualifier either.)

  - You can't take the address of a scope struct, but you can
    take the address of a scope class reference.

  - A scope class variable must be declared with scope, but
    your example indicates that that's not the idea for scope
    structs.


> This is as much as we have in terms of a design right now, so definitely it stands some more fleshing out. If gotten right, scope should allow defining a number of useful idioms, such as pass-down values, unique/lent objects, and the such.

What are pass-down values?  (Yes, I've tried searching for it.)


> Working against escapes has long been a problem, and with scope we're hoping to strike a balance between useful and simple.
> 
> Please share any thoughts you might have.

In brief: I like the idea, but I like the '@disable opUnary!"&"' suggestion better than 'scope struct'.

-Lars

Lars T. Kyllingstad wrote:
> Though the feature seems useful, I worry about the asymmetry with scope classes.  I think it will be very confusing to new D programmers that a scope class and a scope struct have very little to do with each other.

I agree, except I more and more think that scope classes were a mistake. Structs with destructors are a much better solution, and wrapping a class inside a struct would give it RAII semantics.

On 2/8/10 11:05, Walter Bright wrote:
> Lars T. Kyllingstad wrote:
>> Though the feature seems useful, I worry about the asymmetry with
>> scope classes. I think it will be very confusing to new D programmers
>> that a scope class and a scope struct have very little to do with each
>> other.
>
> I agree, except I more and more think that scope classes were a mistake.
> Structs with destructors are a much better solution, and wrapping a
> class inside a struct would give it RAII semantics.

Scope class seems like a workaround in D1 because it doesn't got structs with constructors and destructors. If scope classes are up for removal shouldn't struct constructors be fixed to allow to do the same as class constructors? For example, allow empty parameter lists.


/Jacob Carlborg

Walter Bright Wrote:

> Lars T. Kyllingstad wrote:
> > Though the feature seems useful, I worry about the asymmetry with scope classes.  I think it will be very confusing to new D programmers that a scope class and a scope struct have very little to do with each other.
> 
> I agree, except I more and more think that scope classes were a mistake. Structs with destructors are a much better solution, and wrapping a class inside a struct would give it RAII semantics.

stack allocs will be quite a hack...

Lars T. Kyllingstad wrote:
> Andrei Alexandrescu wrote:
>> Following work on typechecking synchronized methods, Walter and I were discussing about managing escaping references to objects that wouldn't actually agree to escaping. The problem is that today a value has no idea that its address is being taken, so it has no saying in that.
>>
>> To compensate for that, my idea was to allow @disable on opUnary!"&". Walter suggested allowing "scope" as a property of a struct:
>>
>> scope struct Transitory
>> {
>>     ...
>> }
>>
>> A scope struct cannot have its address taken. You can take addresses of its members (access permitting), but you can't take the address of any other struct that has at least one scope struct as a direct member. For example:
>>
>> struct A
>> {
>>     int x;
>>     Transitory tr;
>> }
>>
>> A will also be scope. So scope has this funny way of propagating outwards, as opposed to qualifiers, which propagate inwards.
> 
> Though the feature seems useful, I worry about the asymmetry with scope classes.

Scope classes will be eliminated from the language.

Andrei

On 2010-02-08 00:27:29 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Following work on typechecking synchronized methods, Walter and I were discussing about managing escaping references to objects that wouldn't actually agree to escaping. The problem is that today a value has no idea that its address is being taken, so it has no saying in that.
> 
> To compensate for that, my idea was to allow @disable on opUnary!"&". Walter suggested allowing "scope" as a property of a struct:
> 
> scope struct Transitory
> {
>      ...
> }
> 
> A scope struct cannot have its address taken. You can take addresses of its members (access permitting), but you can't take the address of any other struct that has at least one scope struct as a direct member. For example:

Are you saying by "you can take addresses of its member" that it's up to the struct implementation to not leak the address of a member? (by making members private and propagating access only through proxy scope structs?)

I'd say that it looks useful, but it can't do much by itself. That's just one piece of the puzzle and without other pieces it won't go very far. Consider this:

	scope struct Transitory(O) {
		private O o;
		
		this(string s) { o = new O(s); }
		string toString() { return o.toString(); }
	}

	Transitory!MyObject t = Transitory!MyObject("hello");
	t.toString();

This code has two issues:

1. MyObject's constructor could leak a reference.
2. MyObject's toString could leak a reference.

Do we need a "scope class" for this to work?


> A scope struct cannot have its address taken. You can take addresses of its members (access permitting), but you can't take the address of any other struct that has at least one scope struct as a direct member. For example:
> 
> struct A
> {
>      int x;
>      Transitory tr;
> }
> 
> A will also be scope. So scope has this funny way of propagating outwards, as opposed to qualifiers, which propagate inwards.

I'm not sure why you need that. If Transitory is scope, then you can't take tr's address. Taking the address of A doesn't give you the address of tr (in reality it might be the same address, but it'll be typed as A and won't allow you to get the address of tr anyway). So why does A need to be scope?


> This is as much as we have in terms of a design right now, so definitely it stands some more fleshing out. If gotten right, scope should allow defining a number of useful idioms, such as pass-down values, unique/lent objects, and the such.

That'd be really great.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Andrei Alexandrescu wrote:
> Following work on typechecking synchronized methods, Walter and I were discussing about managing escaping references to objects that wouldn't actually agree to escaping. The problem is that today a value has no idea that its address is being taken, so it has no saying in that.
> 
> To compensate for that, my idea was to allow @disable on opUnary!"&". Walter suggested allowing "scope" as a property of a struct:
> 
> scope struct Transitory
> {
>     ...
> }
> 
> A scope struct cannot have its address taken. You can take addresses of its members (access permitting), but you can't take the address of any other struct that has at least one scope struct as a direct member. For example:
> 
> struct A
> {
>     int x;
>     Transitory tr;
> }
> 
> A will also be scope. So scope has this funny way of propagating outwards, as opposed to qualifiers, which propagate inwards.
> 
> This is as much as we have in terms of a design right now, so definitely it stands some more fleshing out. If gotten right, scope should allow defining a number of useful idioms, such as pass-down values, unique/lent objects, and the such.
> 
> Working against escapes has long been a problem, and with scope we're hoping to strike a balance between useful and simple.
> 
> Please share any thoughts you might have.

Why is this useful?

Andrei Alexandrescu:
> Scope classes will be eliminated from the language.

Isn't it better to remove scope classes after a good escape analysis is implemented in the front-end?

Bye,
bearophile

bearophile wrote:
> Andrei Alexandrescu:
>> Scope classes will be eliminated from the language.
> 
> Isn't it better to remove scope classes after a good escape analysis
> is implemented in the front-end?


Escape analysis can still be used to put class instantiations on the stack - it's just that that will be a compiler optimization, not a user one.