Community

I found a slideshow called 'The Expressiveness of Go' recently. The conclusions are:
* Go is not a small language but it is an expressive and comprehensible one.
* Expressiveness comes from orthogonal composition of constructs.
* Comprehensibility comes from simple constructs that interact in easily understood ways.
* Build a language from simple orthogonal constructs and you have a language that will be easy and productive to use.
* The surprises you discover will be pleasant ones.
----
Is D orthogonal? Could it be more orthogonal? Two things come to my mind: removing special cases and making widely used things first class. For data types this means that they have literals, can be given to functions and returned from functions. I made a small test and found that the discoveries aren't pleasant to me:
class A {}
class B : A {}
class C : A {}
template T(A...) { alias A T; }
void main() {
auto a = true ? new B : new C;
// these don't work - why?
// auto b = [new B, new C];
// auto c = { return [1: new B,2: new C]; };
T!(int,int) e = (1,2);
e = T!(3,4);
// ah - so (1,2) syntax on initialization, T!(1,2) when assigning!
T!(int,int) d = T!(1,2);
e = d;
// tuples aren't first class, why?
// auto f = { return e; };
}

> // these don't work - why?
> // auto b = [new B, new C];
> // auto c = { return [1: new B,2: new C]; };
That seems to be just a matter of improving the compiler to make it
find the common type. I don't think there's anything in the language
stopping that from working.

Torarin Wrote:
> > // these don't work - why?
> > // auto b = [new B, new C];
> > // auto c = { return [1: new B,2: new C]; };
>
> That seems to be just a matter of improving the compiler to make it
> find the common type. I don't think there's anything in the language
> stopping that from working.
This is another one of those low priority issues. Never seen this kind of code in practice. These examples are highly synthetic and come from advocates of "clean" simple languages. "No corner cases" - does it matter if the language is full of broken corner cases if the practical real world code just works? D isn't nowhere near that bad.
Other than that, I'm quite sure compiler construction isn't that straightforward. You can't use the same type deduction code of "? :" in this context. A functional kid might say, if you have infer(a,b) and reduce(), you can solve this, but you have to consider metaprogramming and all complex stuff in D. Otherwise this would work already.