www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2's feature set?

reply "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... :)
Jun 06 2009
parent reply 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.
Jun 06 2009
next sibling parent "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).)
Jun 06 2009
prev sibling next sibling parent "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
Jun 06 2009
prev sibling next sibling parent 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.
Jun 06 2009
prev sibling next sibling parent 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
Jun 06 2009
prev sibling next sibling parent 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
Jun 06 2009
prev sibling parent 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
Jun 06 2009