Which language futures make D overcompicated?

[Atila Neves]

On Friday, 9 February 2018 at 15:25:51 UTC, jmh530 wrote:
> On Friday, 9 February 2018 at 13:47:51 UTC, Atila Neves wrote:
>> On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky
>>>
>>> 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...")
>>>
>>> [...]
>>
>> Yeah, something like traits in Rust or typeclasses in Haskell 
>> would be a lot better. Fortunately, one can kinda-sorta get 
>> there with a library solution. Check out `@implements` in 
>> https://github.com/atilaneves/concepts
>>
>
> I'm confused. While I get how @implements resolves the same 
> issues as Rusts's traits, I don't see how traits resolve the 
> same issues as inout/auto ref. My understanding is that inout 
> and auto ref mean you don't have to write multiple versions of 
> the relevant functions. Moreover, while one could use templates 
> to do something similar, inout/auto ref are designed to reduce 
> code bloat. I don't think Rust's traits can accomplish the same 
> thing, but I'm not familiar enough with Haskell's typeclasses 
> to know.

I must have quoted the wrong thing. I posted @implements in 
response to CT vs RT when it comes to interfaces. Think 
isInputRange vs an interface. Rust's traits allow one to use what 
looks like an interface in D (or Java, etc.) for compile-time 
contraints that also works at runtime. I wish we had that.

I wasn't saying anything about inout/auto ref although I like 
both of those.

Atila