seeding the pot for 2.0 features

[Pragma]

BCS wrote:
> Now that the big 1.0 is out, I think that we should start considering 
> what to put into 2.0. I don't think we need to rush anything into D yet, 
> but maybe we should start accumulating a list of things to consider.
> 
> One overall thought I had is that it seems the big killer for C++ was to 
> some extent that it is a strict superset of C. Maybe we should avoid 
> this problem and not requiter that D2.0 be backwards compatible at the 
> source level, but only at the ABI level sort of like C and D are now. 
> Anyway, just a thought.

And a good one at that.  But there are two gotchas here that deserve some discussion.

First - You need some way to flag to a compiler which D version is being used.

0) compiler arg that forces one version or the other for all input files (obvious)
1) use a different file extension: ".d2"
2) provide a pragma: "pragma(dversion,2);
3) abuse the version statement: "version dlanguage = 2;"
4) all of the above
5) something else

Second - If the new D stuff were strictly a superset, in terms of syntax and behavior, then only new constructs would 
fail on older compilers; not the other way around.

> Here are a few of my ideas for 2.0.
> 
> 
> 1)  Modules structs and classes can have static this() functions, why 
> functions? If a static nested constructor were allowed for functions, it 
> would allow static function variable to be initialized at load time.

Like this?

void foobar(){
     static uint baz;
     static void this(){  baz = 111; }
}

IMO, this doesn't seem all that useful.  I would much rather have D allow non-static expressions for static 
initializers; which would help cover this case and several others.  Were the evaluation of delegates made to implicitly 
call on conversion to the lvalue's type, then this would work:

void foobar(){
     static uint baz = { return 111; }; // static anon delegate w/implicit call
}

> 
> 
> 
> 2)  Why is there no tupleof property for interfaces? It would allow for 
> some intriguing possibilities.

Agreed. IMO, you should be able to tupleof() *anything* and get a bag of types that describe the target's type in 
detail.  If this is the route D is going to take for reflection, then it must be more expressive.

> 
> 3) promote static foreach to the same level as static if. This with #2 
> could be reel slick.

Yes.  While we can get by utilizing recursion for iteration, it makes some idioms a major PITA.

Honestly, this is how I interpreted Walter's first demonstration of foreach() with tuples the first time around.  It 
wasn't until I started using tuples that I realized that it was non-static.

> 4) I guess that also needs a "implementable function alias". The syntax, 
> not to mention the name, could ues a little work, but I expect you get 
> the picture.

You lost me here.  Care to elaborate? :)


5) I'll contribute one more: a "true closure" syntax.  I really don't care keyword magic is used to make this
work, just as long as it's less verbose than creating a class w/a single method to simulate the same thing.

//old and busted:
int delegate() foobar(int c){
     return { return c; }; // delegate references current stack frame - this is worse than broken.
}

//new hotness:
int delegate() foobar(int c){
     return final{ return c; }; // delegate is propped up by copy of the context that is on the heap
}

It doesn't need to use 'final' per-se - any keyword that isn't confusing will do (like 'alias').  The problem, as you 
can imagine, is a pain to implement and has some non-trival side-effects of its own (like aliasing a stack frame that 
has inout parameters).  This really needs some discussion.

-- 
- EricAnderton at yahoo