On Monday, March 13, 2017 23:40:55 Dmitry Olshansky via Digitalmars-d wrote: > On 3/13/17 8:08 PM, H. S. Teoh via Digitalmars-d wrote: > > Ugh. What a horrible mess! > > > > I think, instead of wading through the specifics and losing sight of the > > forest for the myriad trees, we should take a step back and consider the > > big picture. > > [snip excellent answer] > > This is IMHO the right way forward. We (Phobos maintainers) created the > mess, now it's time to cleanup but not at the expense of the user. > All the isSomeString, isSomeOtherString can just be a reminiscent of the > old days that is internal to the implementation.
That makes sense for the APIs of public-facing functions. However, at least some portion of programmers who are not writing Phobos functions are going to need to use all of those same traits to write their own code. In most cases, we can clean up the APIs so that they hide the specializations, but anyone who needs to write specializations in their own code will need the same traits that Phobos uses. So, we can reduce the complications and negative impact that come from having to deal with all of these traits in generic code, but we can't actually eliminate it. Best case, the folks that aren't going to bother writing any generic code of their own don't have to worry about it, but anyone writing their own generic code - especially if it involves ranges of characters - is still stuck with the problem in their own code. So, we really can't make the various traits internal - at least not without basically saying that everyone needs to rewrite them in their own code, which is just going to create a different set of problems. Overall though, I completely agree that we should move towards simplifying the template constraints on the public-facing APIs so that the code that doesn't need to use all of the various traits in its public API doesn't. - Jonathan M Davis
