Top 5

[Sean Kelly]

Andrei Alexandrescu wrote:
> Ok, per Aarti's suggestion: without speaking officially for Walter, let 
> me ask this - what do you think are the top issues you'd like to see 
> fixed in D?

It was kind of a stretch to come up with 5 off the top of my head, but 
here they are:

1. There needs to be a way to explicitly declare static closures.  I'd 
be happy if this were the default and "new &fn" created a dynamic 
closure, but I can understand the desire to make the "safe" option the 
default despite its inconsistency with D1.

2. Templates need work, particularly concerning template functions. 
Every time I try to do serious template programming I run into weird 
compile errors for things that seem like they should be fine.  A related 
issue would be the ability to overload template functions with normal 
functions.  Template metaprogramming in D is light years ahead of C++, 
but everyday template programming is often worse.

3. Forwards compatibility from D1 to D2.  This isn't an issue that will 
be a blight upon the language many years from now, but at the moment the 
  changes in meaning for some tokens (enum, const, invariant) make 
writing portable code difficult.  Changing 'invariant' to 'immutable' 
will eliminate the problem with class invariants needing to be defined 
differently between versions however.

4. Tighter restrictions for implicit conversions between concrete types. 
  At the very least, narrowing conversions should be an error.

5a. Dump support for legacy features such as the pre-D1 dual meaning of 
'auto'.  I'd also like to see support for C-style array an function 
pointer declarations dropped.  These aren't a huge issue to me, but I'd 
prefer if D didn't have any such easter eggs.  Drop foreach_reverse 
too--it is a well-intended disaster.

5b. AAs are currently pretty quirky.  It would be nice if the 
functionality could be reviewed and cleaned up.

5c. I'd like to see real support for properties or at least more 
stringent compiler rules regarding the instances where a function can 
and can't be called without parens.  Calling delegates should always 
require the use of parens, for example.  This isn't a show-stopper, but 
the current situation feels like it requires experimentation to make 
sure actual behavior matches expected behavior, and I think this 
wouldn't be an issue with in-language support for properties.

(I wasn't sure which of the 5s I considered most important so I included 
them all.)


Sean