template constraints when non-constrained template exists

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 5 04:22:28 PDT 2015


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


More information about the Digitalmars-d mailing list