Does D have too many features?

[Dmitry Olshansky]

On 29.04.2012 0:57, Timon Gehr wrote:
> On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
>> On 28.04.2012 22:47, Walter Bright wrote:
>>> 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?
>>
>>
>> 1. Drop is(...) feature entirely. Extend __traits where needed and move
>> compile-time reflection to "magic" meta namespace completely.
>>
>> 2. "enum as manifest constant". Use static or immutable/global.
>
> static is not accessible at compile time, would you want to change that?
> immutable is not an option because it infects the type.
>
Oops, scratch that comment about static/immutable.

But how about:
alias thing = runSomeCtfe();

And bring the usual alias to new_name = <something>;
  form (even C++ finally got this right with C++11 aliases).

> Furthermore, I like 'enum' because it is concise.
>
> What is the issue with enum?
>
>> Compiler should be smart enough
>
> Smart compiler fallacy. It really cannot be that smart in this case.
>
>> to avoid putting immutable integers/doubles into
>> object file as variables.
>>
>
> Their address might be taken by code that is unavailable! Furthermore,
> many of my enums are strings or arrays.
>
>> 8. Something else. D is huge :)
>>
>
> I actually think D is not too large.

For what it does - surely not. But in general it's big.
For one it's not smaller then C++.

8. synchronized. scope(exit) mutex.unlock(); is fine in cases where RAII 
is awkward.

-- 
Dmitry Olshansky