Top 5

Denis Koroskin 2korden at gmail.com
Wed Oct 8 15:00:45 PDT 2008


On Thu, 09 Oct 2008 00:07:27 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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?
>
> Andrei

Even though I wrote large amount of templated code, I still have many  
problems with them.

- I can't figure out why static if (is (condition)) works in some cases  
and doesn't in others (sorry, no examples)

- the (T : T), (T : T*), (T : T[]), (T : S!(T)), (T S == class), (T S ==  
T*) etc stuff is not intuitive and hard to understand to me

- I don't like the static if (is (T t)) { } hack to introduce compile-time  
variable of type T in a template level without polluting template  
namespace and without introducing actual variables. Something like this:

template CanAdd(X, Y)
{
     static if (is (X x)) {
         static if (is (Y y)) {
             enum CanAdd = is (x + y);
         } else {
             enum CanAdd = false;
         }
     } else {
         enum CanAdd = false;
     }
}

It is a common practice that deserves better syntax, I believe. There  
might exists solutions that I don't know of, still (after a year+ D  
development).

- static if (is (X[0].Y == Z)) { .. } syntax doesn't work (X is a tuple  
and X[0] is a type that contains Y - alias, manifest constant or type  
name). This might be a bug, I don't know, but I often need it and it is  
bad that I have to do make an explicit alias so that it is usable in the  
is expression.

- I believe conditional template matching is a bad hack that needs to be  
revised:
template Foo(Bar)(Bar bar) if (SomeCheck!(Bar)) { // C++0x concepts are  
thousand time better
    ...
}

- Lack of struct inheritance. I'm having hard time porting and using some  
C++ code (namely GDI+) that relies on struct inheritance. No, I can't make  
them classes because they should remain POD-types. This involves code  
duplication and struct pointer casts (argh!).

- The following code doesn't work:

void foo(T)(T t) {
}

void foo(float f) {
}

I'm having hard time with all the static ifs that complicate the code and  
makes it ugly:

void foo(T)(T t)
{
     static if (is (T == float)) {
         // implementation1 here
     } else if (is (T == Bar)) {
         // implementation2 here
     } else {
         // implementation3 here
     }
}

or

void foo(T)(T t) if (is(T == float)) {
}
	
void foo(T)(T t) if (is (T == Bar)) {
}

void foo(T)(T t) if (!is (T == Bar) && !is (T == float)) {
}

- Template function specialization. I miss this feature from C++ alot. It  
allow user to extend existing library functionality to support user type,  
or make an optimized version.

- version'ing is not smart enough (in my optinion). It doesn't support  
mixing different assembly styles (because DMD doesn't know some op-codes  
that GDC knows, for example), different language versions (D1/D2/D3?) etc.  
There is definitely a room for improvement.

- There are also a few (confirmed) bugs that are annoying and I am looking  
for them to be fixed.

[Wish] Better compile-time reflection. It is currently quite hard to work  
with.
[Wish] (Varible/Template/Function) Attributes. These are priceless for  
compile-time reflection. I can explain them in a separate topic.
[Wish] Named parameters. Compare the following:

updateSettings(true, 32, true);
Color color(255, 0, 255, 100);

with:

updateSettings(fullScreen: true, colorDepth: 32, fastSimulation: true);
Color color(red: 255, green: 0, blue: 255, alpha: 100);

[Minor one] int -> short implicit cast (signed/unsigned comparison without  
error belong here)

[This one is not about D but about its development]
- I dislike some design decisions that are spontaneously made without  
discussion and we all regret about and suffer afterwards
- Some good proposals are made and it is somewhat bad that no one from the  
"higher powers" comments them. I know it is hard to answer everyone, but  
it is a share so much time is wasted on hubbub and good proposals are  
ignored.

On the other hand, now that you are back I am more optimistic about D  
future. Thanks for the time and effort that you put into all this! Thank  
you!



More information about the Digitalmars-d mailing list