On 07/10/2017 11:58 AM, bpr wrote:
You've seen this, right?
https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint
A small step in one such direction, influenced by C++ concepts. That
proto-DIP also raises a question I always had about why D doesn't allow
chained template instantiation, but that's another DIP for another time.
Yea, I've seen that. It'd be a nice improvent for D and I'm definitely
in favor of it.
It doesn't especially excite me though just because it's a small
incremental change and creates further syntactical differences between
handling runtime-oriented symbols and compile-time-oriented symbols. Ie,
I'd prefer "InputRange r" over "T r if InputRange" because it's vastly
simpler and more consistent with non-templated variable declarations.
But in a practical sense, that's be a much more major and difficult to
retrofit that onto D, so the DIP sounds like an appropriate (if
unexciting) direction for D to take.
But what I find much more interesting than that DIP (again, from a
purely academic standpoint) is taking all of these abilities and finding
a way simplify them, while retaining all of their power, and create more
overall consistency[1]. (That was *exactly* one of my big original draws
to D in the first place - it took C++, then cleaned it all up and
enhanced it. I have interest in brainstorming the same for D. I think
there's been enough practical experience using D at this point for more
streamlined designs to now be possible.)
[1] Heck, on the consistency front, it even bugs the hell out of me when
people do "foo()" to call/define a function, but then deliberately stick
with "if ()"-style instead for keywords. Both are "identifier followed
by parens", but whether or not a space is added between is *different*
depending on whether the identifier is a symbol or a keyword.
Unnecessary inconsistency. Maybe it's all the puzzle games I've played
over my lifetime, but...want...to...simplify... ;)
