ranges of characters and the overabundance of traits that go with them

[Jonathan M Davis via Digitalmars-d]

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