Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa)]

On 02/09/2018 02:54 AM, Suliman wrote:
> I like D, but sometimes it's look like for me too complicated. Go have a 
> lot of fans even it not simple, but primitive. But some D futures make 
> it very hard to learning.
> 
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
> 
> Which language futures by your opinion make D harder?
> 

Auto-decode.

Dub.

And yes, things like "inout", "auto ref" or whatever, and such, strike 
me as indicative of more fundamental design flaws. (Not "flaw" in the 
sence of "mistakes" necessarily, but "flaw" in the sence of "there must 
be a better way to design these things...")

Aside from that, I don't think features inherently make D complicated, 
but I do think there are features that are designed or implemented in 
overly-complicated ways. Or *missing* features, which by their absence 
make the langauge more complicated.

The biggest, by far, that comes to my mind is dealing with types:

- At runtime: Dealing with type infos at runtime is a mess compared to 
many other langauges (especially dynamic ones).

- At compile time: The mechanisms for dealing with type info at compile 
time seem...undesigned. It's kind of a clutter of various approaches and 
haphazard quirks, and std.traits is a testament that it's not very 
cleanly designed at the language-level.

- RT vs CT: The interfaces for dealing with types are completely 100% 
different depending whether you're working with runtime or compile-time.

Other things that come to mind:

Defining input ranges (one of my biggest pet peeves):

C# knocked it out of the park ages ago with its design for a 
stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same 
approach couldn't be used in D for creating input ranges. But instead, D 
forces input ranges to be defined the same way as random-access ranges, 
which is a PITA (a necessary PITA for random-access, but unnecessary for 
mere generators like input ranges), and D provides no way around that 
without introducing the overhead of fibers. Even an old version of C# 
from ten years ago puts us to complete shame here.

And Algebraic types. Yes, we technically have them, but compared to 
something like Nemerle, D claiming to have algebraic or pattern matching 
is like C claiming to support OO: 
Umm...sorta...technically...kinda...but...uhhh...no, not really.