On Monday, 5 October 2015 at 11:05:51 UTC, Manu wrote:
I am personally yet to give a single f... care, when any change
that
makes D better also breaks code. And that includes the time
when I was
maintaining a reasonably substantial codebase used commercially.
D is not finished yet, not by a long shot. I'm so bored of this
excuse, it's predictable and seriously tiring. (not from you
specifically, it comes from all angles)
In this case, I really think that we need the traits as they are
now regardless of whether changing them would break anything,
because I think that we need traits like this which work only
with built-in types. Without that, plenty of code is going to
have to use them with one or more additional checks to prevent
user-defined types from matching a template constraint. Having
additional traits that work with both built-in types and
user-defined types would likely be a good idea as well, but that
doesn't make sense for all templates.
But anyway, what do I do? I need to inject one of these types
into a
tree which uses std.traits.
This demonstrates a fairly serious scalability problem. It's
come up
quite some number of times for me.
Well, feel free to create PRs which add the functionality that
you need to Phobos. No matter how good the programmer was who
wrote something in Phobos, they're not omniscient. They may very
well have reasons why what you want to do is a bad idea or why it
should be a separate construct rather than having an existing
construct changed based on what you want, or it could be that
they simply didn't think of your use case. Heck, it could be that
they were aware of it but failed to test for it and wrote the
code in way that it accidentally didn't work with what you wanted
when it was supposed to.
In this particular case, I think that we should create new traits
that test for what you're looking for (rather than altering the
existing ones), and possibly, some of the rest of Phobos should
be changed to use those, but you can certainly create a PR that
solves your problem. And if no one else has the same problem you
do, or if all of the people that do assume that someone else will
take care of it, then Phobos will never get the improvements that
you need even if they are indeed something that the D community
as a whole would benefit from and lots of programmers end up
complaining about not existing.
The traits are one area where we need to be _really_ careful,
since they deal with what will and won't compile with a given
template and can interact in a combinatorial explosion of ways,
many of them with quite surprising results, but there's no
question that they can be improved if only by having more added.
We've primarily ended up with traits simply because someone found
that they needed one and were able to convince the Phobos devs
that it was a general enough need for it to be added, not
necessarily because someone planned ahead really well when
creating std.traits or even when adding new ones.
- Jonathan M Davis
