does D already have too many language features ?

[Paul]

On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
> What I really find as an annoying problem is that almost all D 
> features are half-baked...

I'm curious what you mean with half baked.
I'm also surprised people say there's too many features, when I'm 
of the opinion several features I'd like, that have been stuck in 
DIP hell for like 3 years, would only make the language simpler.
For example:

- I consider the disability to use struct initialization inline 
as an unexpected limitation.
- I think the way tuples currently work is also confusing, it 
requires a lot of looking into aliasSeq & Tuple library stuff.
- Removing the comma operator entirely, as seems suggested in the 
tuple DIP, would remove a feature some people might not use, but 
it's not a complex concept to understand and thus feels like an 
unnecessary limitation.
- static if & static foreach seem like nice features, but their 
naming is not at all logical. Reuse of the 'static' keyword only 
creates confusion. And it's a halfbaked concept too! There is no 
static switch, and I can't have a compiletime only piece of code 
to work with static if & mixin without creating A LOT of manifest 
constants or having to use functions for it. Why have CTFE, 
static if/foreach, mixin but not just CT? (Hence my suggestion of 
using a ct/comp/compile keyword for static if/foreach & new 
compile-time non-constant 'compile' variables)
- I don't know if I'm the only one, but I believe having a 
seperate 'manifest' keyword for manifest constants would make 
them less confusing.
- The inability to create a non-argument constructor for structs 
is one of those edge-cases one doesn't expect and has to make a 
workaround for. Why can't we have this?

TLDR; Sorry for the rant, I'm just of the opinion that no, there 
are not too many features in D.
Rather the opposite, I'm of the opinion D has a DIP hell problem.