Does D have too many features?

[Timon Gehr]

On 04/29/2012 08:31 AM, Paulo Pinto wrote:
> Am 28.04.2012 20:47, schrieb Walter Bright:
>> Andrei and I had a fun discussion last night about this question. The
>> idea was which features in D are redundant and/or do not add significant
>> value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>> and creal types.
>>
>> What's your list?
>
> - two different ways of creating function pointers is confusing
> (function and delegate)
>
> I understand the reasoning, but makes one think all the time when
> to use what.
>

'delegate' is more powerful, 'function' is more efficient. If you don't 
want to think about it, just use 'delegate'. I'd rather see 'function' 
implicitly convert to 'delegate' than to have it gone. D can be used for 
systems programming after all!

> - sometimes D code looks like template and mixins gone mad
> While I do appreciate the power, it can be quite confusing to try
> to understand what the code does. Specially with the lack of support
> in mixin's debugging
>

pragma(msg, ...) ?

>
> - misuse of enum to declare constants
> I prefer that the use of const would be possible
>

const infects the type and const-qualified data can exist at runtime, so 
it is not possible.

> - conditional compilation is hard to follow without syntax highlighting
> Other languages with conditional compilation make it easier to follow
> what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada
>

That is not a language issue.


> While it is fun to discuss what we like and not like, I vote that
> priority should be given to make the language stable and have better
> tooling.
>
> We need to have safer languages with native code generation for systems
> programming in the mainstream OS, that take us away from the buffer
> overflow exploits and dagling pointers legacy that C and C++ brought
> upon us.
>
> Someone that does not know D and sees the amount of bugs still existing,
> or this type of discussions, will run away to Go or some future version
> of C#/Spec#/Bartok, or back to whatever he/she was using before.
>
> I don't agree D is complex, any language that aims to be used in large
> application domains, needs a certain set of abstractions. If it does not
> support them, it is condemmend to keep getting new features until it
> turns in what the language designers were fighting against.
>

I agree with this section.