• "Kristian Kilpi" <kjkilpi gmail.com> Jun 06 2009
• Christopher Wright <dhasenan gmail.com> Jun 06 2009
• "Kristian Kilpi" <kjkilpi gmail.com> Jun 06 2009
• "Steven Schveighoffer" <schveiguy yahoo.com> Jun 06 2009
• Jarrett Billingsley <jarrett.billingsley gmail.com> Jun 06 2009
• Steve Schveighoffer <schveiguy yahoo.com> Jun 06 2009
• Brad Roberts <braddr puremagic.com> Jun 06 2009
• Steve Schveighoffer <schveiguy yahoo.com> Jun 06 2009

"Kristian Kilpi" <kjkilpi gmail.com> writes:

I think I shouldn't post this because I could very well start one of those  
mega-threads... :D

Of course, only Walter & Co know what D2 will include when it's finally  
'released'. Concurrency stuff has been developed lately. But something  
more? Or is that it? What do you think?


I haven't thought about it too much, but lets say something... ;)

1) Scoped members. For example:

class Foo
{
      scope Bar bar;  // gets destructed with Foo object
}


2) There have been threads about the import/package system. So maybe it  
could be improved as well. (I'm not gonna discuss it more here.) But yeah,  
I guess this would require too much work to be done within D2's schedule.


Oh, macros would also be nice, but maybe they will/should wait for D3... :)

Christopher Wright <dhasenan gmail.com> writes:

Kristian Kilpi wrote:
 
 I think I shouldn't post this because I could very well start one of 
 those mega-threads... :D
 
 Of course, only Walter & Co know what D2 will include when it's finally 
 'released'. Concurrency stuff has been developed lately. But something 
 more? Or is that it? What do you think?
 
 
 I haven't thought about it too much, but lets say something... ;)
 
 1) Scoped members. For example:
 
 class Foo
 {
      scope Bar bar;  // gets destructed with Foo object
 }


You need to do escape analysis and whole program analysis to determine 
whether there are aliases to a scope member. Failing that, it's pretty 
easy to introduce bugs that are difficult to find.

It would be fine as long as you always assign with a NewExpression.

"Kristian Kilpi" <kjkilpi gmail.com> writes:

On Sat, 06 Jun 2009 16:35:15 +0300, Christopher Wright  
<dhasenan gmail.com> wrote:

 Kristian Kilpi wrote:
  I think I shouldn't post this because I could very well start one of  
 those mega-threads... :D
  Of course, only Walter & Co know what D2 will include when it's  
 finally 'released'. Concurrency stuff has been developed lately. But  
 something more? Or is that it? What do you think?
   I haven't thought about it too much, but lets say something... ;)
  1) Scoped members. For example:
  class Foo
 {
      scope Bar bar;  // gets destructed with Foo object
 }


 You need to do escape analysis and whole program analysis to determine  
 whether there are aliases to a scope member. Failing that, it's pretty  
 easy to introduce bugs that are difficult to find.

 It would be fine as long as you always assign with a NewExpression.


Yep. Well, I would be happy with it even if you could only assing newly  
created objects to a scoped member. (And you could always remove this  
restriction when the escape analysis will be available (if ever).)

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright  
<dhasenan gmail.com> wrote:

 Kristian Kilpi wrote:
  I think I shouldn't post this because I could very well start one of  
 those mega-threads... :D
  Of course, only Walter & Co know what D2 will include when it's  
 finally 'released'. Concurrency stuff has been developed lately. But  
 something more? Or is that it? What do you think?
   I haven't thought about it too much, but lets say something... ;)
  1) Scoped members. For example:
  class Foo
 {
      scope Bar bar;  // gets destructed with Foo object
 }


 You need to do escape analysis and whole program analysis to determine  
 whether there are aliases to a scope member. Failing that, it's pretty  
 easy to introduce bugs that are difficult to find.


Not really.  A scope member would be placed in the same memory block as  
the owner class.  So an alias to the member would be the same as an alias  
to the owner class because the same memory block would be referenced.   
Both wouldn't be collected until neither is referenced.

It's the equivalent of this in C++:

class Bar
{
}
class Foo
{
   Bar bar;
}

The only issue left to decide is how the member is initialized.  There  
must be some rules, like if bar has no default constructor, it must be  
new'd in the constructor.  And it can't be rebound.

-Steve

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Sat, Jun 6, 2009 at 11:17 AM, Steven
Schveighoffer<schveiguy yahoo.com> wrote:
 You need to do escape analysis and whole program analysis to determine
 whether there are aliases to a scope member. Failing that, it's pretty e=




 to introduce bugs that are difficult to find.


 Not really. =A0A scope member would be placed in the same memory block as=


 owner class. =A0So an alias to the member would be the same as an alias t=


 owner class because the same memory block would be referenced. =A0Both
 wouldn't be collected until neither is referenced.


Regardless of how/where it's allocated, Chris is still right, unless
'scope' becomes a type constructor instead of a storage attribute.
Consider:

class A
{
    void fork() { writeln("fork!"); }
}

class B
{
    scope A a;
    this() { a =3D new A(); }
}

A a;

void foo()
{
    scope b =3D new B();
    a =3D b.a; // waaait
}

void main()
{
    foo();
    a.fork(); // AGHL
}

If it were impossible to assign a "scope A" into an A, this wouldn't
be a problem.  Or, full escape analysis, either way.

Steve Schveighoffer <schveiguy yahoo.com> writes:

On Sat, 06 Jun 2009 11:26:37 -0400, Jarrett Billingsley wrote:

 On Sat, Jun 6, 2009 at 11:17 AM, Steven
 Schveighoffer<schveiguy yahoo.com> wrote:
 You need to do escape analysis and whole program analysis to determine
 whether there are aliases to a scope member. Failing that, it's pretty
 easy to introduce bugs that are difficult to find.


 Not really.  A scope member would be placed in the same memory block as
 the owner class.  So an alias to the member would be the same as an
 alias to the owner class because the same memory block would be
 referenced.  Both wouldn't be collected until neither is referenced.


 Regardless of how/where it's allocated, Chris is still right, unless
 'scope' becomes a type constructor instead of a storage attribute.
 Consider:
 
 class A
 {
     void fork() { writeln("fork!"); }
 }
 
 class B
 {
     scope A a;
     this() { a = new A(); }
 }
 
 A a;
 
 void foo()
 {
     scope b = new B();
     a = b.a; // waaait
 }
 
 void main()
 {
     foo();
     a.fork(); // AGHL
 }
 
 If it were impossible to assign a "scope A" into an A, this wouldn't be
 a problem.  Or, full escape analysis, either way.


You are looking at a different problem.  This problem already exists:

A a;
void foo()
{
  scope al = new A();
  a = al;
}

I'm talking about scope members, that is, members whose storage is 
contained within the owner.  This allows destructors to access members 
before the members' memory is destroyed, because both the member and the 
owner's memory is destroyed at the same time.

There would have to be some special treatment for a scope member by the 
compiler -- the member should not be rebindable, and I think you would 
not need to store a separate reference to the member, because it's 
reference address is statically decided.  In other words, yes, scope 
members would be treated differently, but I don't think scope needs to be 
a type constructor for that.

-Steve

Brad Roberts <braddr puremagic.com> writes:

Steven Schveighoffer wrote:
 On Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright
 <dhasenan gmail.com> wrote:
 
 Kristian Kilpi wrote:
  I think I shouldn't post this because I could very well start one of
 those mega-threads... :D
  Of course, only Walter & Co know what D2 will include when it's
 finally 'released'. Concurrency stuff has been developed lately. But
 something more? Or is that it? What do you think?
   I haven't thought about it too much, but lets say something... ;)
  1) Scoped members. For example:
  class Foo
 {
      scope Bar bar;  // gets destructed with Foo object
 }


 You need to do escape analysis and whole program analysis to determine
 whether there are aliases to a scope member. Failing that, it's pretty
 easy to introduce bugs that are difficult to find.


 Not really.  A scope member would be placed in the same memory block as
 the owner class.  So an alias to the member would be the same as an
 alias to the owner class because the same memory block would be
 referenced.  Both wouldn't be collected until neither is referenced.
 
 It's the equivalent of this in C++:
 
 class Bar
 {
 }
 class Foo
 {
   Bar bar;
 }
 
 The only issue left to decide is how the member is initialized.  There
 must be some rules, like if bar has no default constructor, it must be
 new'd in the constructor.  And it can't be rebound.
 
 -Steve


Can't work like that since it's subject to the object slicing problem.  Class
size can't be known in advance since subclasses can add an arbitrary amount of
additional storage requirements.  If you restrict it to structs or other value
types, then it could work but would be awfully restrictive.

Later,
Brad

Steve Schveighoffer <schveiguy yahoo.com> writes:

On Sat, 06 Jun 2009 10:57:08 -0700, Brad Roberts wrote:

 Steven Schveighoffer wrote:
 On Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright
 <dhasenan gmail.com> wrote:
 
 Kristian Kilpi wrote:
  I think I shouldn't post this because I could very well start one of
 those mega-threads... :D
  Of course, only Walter & Co know what D2 will include when it's
 finally 'released'. Concurrency stuff has been developed lately. But
 something more? Or is that it? What do you think?
   I haven't thought about it too much, but lets say something... ;)
  1) Scoped members. For example:
  class Foo
 {
      scope Bar bar;  // gets destructed with Foo object
 }


 You need to do escape analysis and whole program analysis to determine
 whether there are aliases to a scope member. Failing that, it's pretty
 easy to introduce bugs that are difficult to find.


 Not really.  A scope member would be placed in the same memory block as
 the owner class.  So an alias to the member would be the same as an
 alias to the owner class because the same memory block would be
 referenced.  Both wouldn't be collected until neither is referenced.
 
 It's the equivalent of this in C++:
 
 class Bar
 {
 }
 class Foo
 {
   Bar bar;
 }
 
 The only issue left to decide is how the member is initialized.  There
 must be some rules, like if bar has no default constructor, it must be
 new'd in the constructor.  And it can't be rebound.
 
 -Steve


 Can't work like that since it's subject to the object slicing problem. 
 Class size can't be known in advance since subclasses can add an
 arbitrary amount of additional storage requirements.  If you restrict it
 to structs or other value types, then it could work but would be awfully
 restrictive.


Structs are already part of the class data.  I don't believe something 
like this will work

class A : B {}
class C
{
   scope A a;
   this() {a = new B;}
}

It would not work any differently than how scope classes are allocated on 
the stack.  Just instead of the stack, you are allocating the scope class 
inside the class data instead of a stack (well, if the owner class was 
allocated on the stack, it would be on the stack).  You would not have 
any slicing issues.  Either:

1. The class contains not only the member class data but also a reference 
to it (and in this case, the reference could be re-bound).
2. The class can not reassign the member once it is assigned (i.e. head-
const).  When it passes the class member to a function, the compiler 
would pass a reference to the contained class data.  This is what I was 
expecting.

The benefit would be that you can control the destruction order of the 
members in the owner's destructor.

-Steve