[phobos] isStringLike

[Andrei Alexandrescu via phobos]

Hi folks, isStringLike is a fine idea but there are a number of issues I 
noticed while looking at the PR and the related pieces it works with.

1. isAggregate is not the best choice of names for something that's a 
struct, class, union, or interface. In C++ aggregates are a completely 
different notion 
(http://stackoverflow.com/questions/4178175/what-are-aggregates-and-pods-and-how-why-are-they-special) 
so essentially we're defining our own terminology. Not the best thing to 
do. Closest term I can think of is isUserDefinedType, but that would 
include enumerated types.

The larger question is why this peculiar notion is needed strongly 
enough to get its own name.

2. I take issue with the current definition of isStringLike, which is:

  (isAggregateType!T || isStaticArray!T) && is(StringTypeOf!T);

So... a string is unlike a string, which I find unfitting. Furthermore, 
the entire notion of isStringLike and StringTypeOf is dedicated to work 
around what seems to be a bug in the typesystem (alias this fails to 
implement real subtyping). It seems that is the right place to focus 
work on.

A worse problem is that isStringLike fails to capture the more frequent 
"string-like" structure: (a) lazy ranges of characters and (b) reference 
counted strings. These are crucial pieces. So we're not making progress 
toward actually defining what we think a string-like data structure is.

I think a string-like structure is:

(a) an array of characters or a subtype thereof

(b) some other forward range with ElementType some character type, and 
potentially ElementEncodingType a different character type as well.

That's pretty much it. Algorithms dealing with string-like data should 
be able to work with this definition, or temporarily convert to arrays 
of characters.

More importantly, while looking at 
https://github.com/D-Programming-Language/phobos/pull/3770/ and related 
work I can't stop noticing a growth of layers of complexity that seems 
poorly scalable, instead of an increase in generic simplicity and 
clarity of concepts. That does not bode well and we need to curb it lest 
we end up with a standard library we ourselves can't make sense of.

I do understand there are issues to fix and we need to move forward. But 
tactical solutions cannot substitute a lack of strategy.

Please let us all stop and draw a little breath, and figure out how to 
replace the monumental work in PR 3770 with simplifying abstractions. 
Once something like isStringLike becomes part of Phobos, we're stuck 
with it for eternity - there's no way we can fix it without breaking code.

I don't have the bandwidth to scrutinize all Phobos changes and at the 
same time work on refcounted safe collections (my focus). But please 
keep me informed of all public name additions to Phobos, and also 
discuss them in the forum. If we keep on introducing new notions at this 
pace, we'll drown Phobos in its own attempts at being rigorous.


Thanks,

Andrei