does D already have too many language features ?

[Basile B.]

On Thursday, 28 January 2021 at 15:30:52 UTC, Paul wrote:
> 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.

Yeah struct literals as primary epression you mean.
This request comes back often.

People don't always realize but the semantics of struct literals,
**without touching to the syntax**, would be difficult to 
implement.

The type of the expression, so the struct type, in particular 
would have to
be always deduced from other expressions while for other 
primaries the content gives the type **immediatly**.

   void foo(T)(T t){}
   foo({a:10, b:8}) // huh ...

Impossible.

   void foo(T : S)(T t){}
   foo({a:10, b:8}) // okay but painful...

So here you see that to retrieve the literal type you can use the 
template type specalization. But that's not a natural way of 
doing things.

> - 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.

Slight ptoblem for `for` ;). Also note that it is used
everywhere in the compiler as a way to insert expressions,
e.g dtor calls, so most of the compiler code would have to remain