Which language futures make D overcompicated?

Dukc ajieskola at gmail.com
Sat Feb 10 09:54:20 UTC 2018


On Friday, 9 February 2018 at 18:31:18 UTC, H. S. Teoh wrote:
> 
> TBH, I'm not a fan of inout. Not because of how most people 
> feel, that we shouldn't have it; IMO it doesn't go *far 
> enough*.  For example, there's currently no way to express 
> conveying the constness of a delegate argument's parameter to 
> the return value, which would have been useful in some places 
> in generic code.
>

So it's in your list of wanted stuff, not in your list of excess 
stuff. We're in agreement here.

>> What I would like to remove, is auto-decoding (popular 
>> opinion, I know)
>
> I would totally back up killing auto-decoding. With fire. And 
> extreme prejudice. :-P
>
> barring some kind of workable (probably very long) deprecation 
> cycle, I just don't see it going away anytime in the 
> foreseeable future.

If we had something similar to c++ template lookup, it would, as 
I see it, finally solve that, along with many other problems. But 
bring some others, it's said... Better wrapper writing way than 
alias this would also solve it mostly and without the ADL 
problems, but there would still remain a problem with string and 
char literals.

>> __traits, is expression, typeof and std.meta templates should 
>> be invokable in a more UFCS-like manner
>
> As for is-expressions, I think either Walter or Andrei 
> (possibly both) have acknowledged that the syntax is a mess.  
> But too much code already depends on the current syntax, and 
> changing that now will be far too disruptive.

But UFCS style also allows the traditional way, there would be no 
breakage. So I quess that even here the existing thing is there 
for a reason after all.



After reading Manus list, I think I agree with his point 1.




More information about the Digitalmars-d mailing list