On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
[snip]
The way I saw it the whole argumentation for a language change
went like this:
9il: This would be helpful for my lib
Atila: Im not convinced this is good addition to the language
Thats it. No more good arguments came later. If proposal has
only this kind of argument then ofcourse it will be rejected.
Even if the idea is good.
You should put yourself in the boots of Atila. If you accept a
change that later turns out to be bad idea you cant just take
it out. We all would have to be with it for 10 or more years.
So to avoid situation that I described a proposal needs to have
solid argumentation and cost/benefit ratio needs to be clear to
make good decision.
What happened was more that Atila said why not use template
constraints and Ilya replied it makes things overly complicated
and Atila responded about a workaround existing and he didn't see
why to add.
Obviously, if Atila or Walter is not in favor of something, it's
usually better to know that sooner rather than later. However, it
is a bit unfortunate that this never made its way farther through
the DIP process. There was a first round review, but I think it
was postponed before formal assessment.
And for the end I want to point out that your proposal is not
in the same category as ast macros. If you or some one else
comes up with solid arguments then the outcome might be
different. As for me. Im do not know ins and outs of templates
to make a judgment if your proposal is good or not. No one
showed how it would benefit the code I write.
If you aren't writing templates, then it wouldn't affect you.
However, it was deemed beneficial enough that a form of it was
added to C++ as part of C++ 11 (was news to me as I rarely write
C++). The paper on it is here [1], though it doesn't really get
into the benefits of it. I'm sure there is a lot of C++ 11 and
later code out there that uses the C++11 version of the idea.
Nevertheless, there are some differences between the C++11
template aliases and these. C++11 adds the using syntax in
addition to the typedef syntax. D already has the alias syntax,
which is like using. The difference is that D's template alias
syntax works when defining variables. It only doesn't work the
same with type deduction in functions. In addition, one reason
the DIP was postponed because it really had only addressed the
short form template alias, not the long form. However, the C++
version only seems to support the equivalent of the short form.
Regardless, the DIP likely could have been improved by mentioning
its inclusion in C++ 11 (and perhaps focused a bit less on
implementation).
I wonder if the inability to do this would inhibit the ability of
D code to interact with C++ code bases. For instance, what if you
have a C++ function that takes a template alias and try to call
it in D. Would you have to write out the target of the alias to
get it to work? This kind of thing could be important. You
wouldn't be able to use the same template aliases in D the way
you use them in C++.
If the DIP remained focused on C++ compatibility (if that is an
actual issue), then it would only need to support the short form
syntax (though that may raise questions as to why not support
both).
[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf
