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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
