Does D have too many features?

[Timon Gehr]

On 04/29/2012 05:17 PM, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 02:35:07AM -0400, Nick Sabalausky wrote:
>> "Timon Gehr"<timon.gehr at gmx.ch>  wrote in message
>> news:jnhpvv$ih4$1 at digitalmars.com...
> [...]
>>> Implementing a compiler is probably harder for D, because of the
>>> interplay of forward references, CTFE and compile time
>>> introspection.
>>
>> Those make D more difficult to implement than many languages, but
>> OTOH, AIUI, C++ has some real nightmarish details with templates and
>> even just simply parsing. Probably some other bizarre cruft, too.
>> IIRC, I think Walter's occasionally mentioned something about
>> the...overload rules?
> [...]

C++ implementation complexity is incidental.

>
> It has been said that C++ cannot be lexed before it's parsed.  Before
> C++11, for example, this is invalid:
>
> 	std::vector<std::vector<T>>  nestedList;
>
> Instead, you have to write:
>
> 	std::vector<std::vector<T>  >  nestedList;
>
> Fortunately they fixed this in C++11. But now you have another problem:
>
> 	std::vector<myTemplate<T>>1>  nestedList;
>
> Whether or not this is valid depends on whether T is a type name or a
> variable name

I think it is never valid.

> (e.g., if myTemplate takes an int parameter). But how is
> the lexer even supposed to know whether the>>  should be a right shift
> operator or two right angle brackets? It has to understand the
> _semantics_ of T before it can even lex the thing.
>

A D compiler has to semantically analyse the code without full 
information about which symbols are declared, (getting the full set of 
declared symbols is actually an ill-defined problem because conditional 
compilation is Turing complete and can already depend on any declared 
symbol or even on the fact that a certain symbol has _not_ been 
declared). There might also be ambiguities or contradictions in the code 
that a compiler should detect.

There is no mention of this issue or its (necessarily conservative and 
somewhat arbitrary) solution in the language documentation. DMD does not 
solve the problem, but just fails in funny ways when faced with a 
non-trivial instance of it.

C++ does not have such issues at all because it disallows forward 
references!


Don't get me wrong, I think this is rather awesome. But I predict it 
will be somewhat of a roadblock for getting the language into a stable 
state.


> I read somewhere that one of D's goals was to be able to lex the
> language without requiring semantic knowledge in the lexer.

This is required in order to have forward references.

> You have no idea

I do.

> how much such a seemingly-obvious concept can save hours, days,
> nay, months and years of frustration in compiler implementation.
>
> So you think D is hard to implement? We have barely even begun to delve
> into the insane convolutions of C++. You'll start to have some real
> hair-tearing sessions once you start getting into implicit conversion
> rules

Well, again, DMD does not get those right. And there is some black magic 
in that area, because the implicitly-converts-to-relation is from 
expressions to types instead of from types to types. (which is awesome 
of course, but it is complex to get right).

Try this (this *should* compile).

pragma(msg, typeof(1?[[]]:[[1]]));
pragma(msg, typeof(1?1?[[]]:[[]]:[[1]]));
pragma(msg, typeof([[[]],[[]],[[1]]]));

class C{}
static C[] c = [null];
pragma(msg, typeof([[null],[new C]]));


> and template best-match algorithms. Be glad, be very glad that we
> have D instead of C++!
>

static if(!is(typeof(foo))) enum bar = 1;
static if(!is(typeof(bar))) enum foo = 1;


In D, most of the complexity stems from its advanced features, while in 
C++ a lot of the complexity is merely incidental.