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