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

[H. S. Teoh via Digitalmars-d]

On Mon, Mar 13, 2017 at 04:00:57PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Monday, March 13, 2017 23:40:55 Dmitry Olshansky via Digitalmars-d wrote:
[...]
> > 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 which case even the more we need to clean up our act.  I would dread
user code starting to use isSomeString, isImplicitlyConvertibleToString,
and all of those messy same-but-different templates, introducing subtle
corner cases that the user may not be fully aware of.


> 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.

To be quite honest, in *my* own code I avoid Phobos templates of the
isSomeString category like the plague.  Part of this whole mess came
from autodecoding (and here we again see it rear its ugly head), without
which many of these templates wouldn't need to exist in the first place.
In user code, I'd say either work directly with char[] and its variants,
or byGrapheme if you care about visual "characters", and avoid wstring
and dstring like the plague.  At the most I'd just say:

	auto myFunc(R)(R range)
		if (isInputRange!R && is(ElementType!R : dchar))
	...

and let it be.  This will handle any string, autodecoding or not,
user-defined char/wchar/dchar ranges, and whatever else you throw at it.
If it's truly generic code, it really shouldn't care what it is.  And on
this point, I find Phobos code excessively convoluted -- arguably
necessitated by the historical blunder of autodecoding -- supposedly
generic code really *shouldn't* distinguish between a range of char that
happens to be an array vs. a range of char that isn't.

Actually, come to think of it, the only time isNarrowString, et al are
*necessary* is in the autodecoding parts of Phobos.  I can't think of
any other places where generic code should even care whether something
is a narrow string, or an array-based char range or a non-array-based
char range.  Didn't we agree to move Phobos away from autodecoding, and
only those parts that are truly necessary for backward compatibility
should retain the autodecoding code?  If so, I'd hardly say user code
should even *know* about isNarrowString and friends.


> 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.
[...]

On the contrary, we need to make the *current* traits internal.
Providing users with similar traits -- a much cleaner, orthogonal set of
traits that has none of the current mess -- is a different question. In
principle I agree with doing that, but I don't agree that users should
be using any of the current almost-the-same-but-subtly-different traits.


T

-- 
MASM = Mana Ada Sistem, Man!