RFC: Case-Insensitive Strings (And usually they really do *have* case)

[Jonathan M Davis]

On Sunday 09 January 2011 13:52:53 Jim wrote:
> I'm a firm believer of alternative B: Store the string with its original
> case, unless it's particularly important to do otherwise.
> 
> The cost of case-insensitive comparison is REALLY small. Anytime you are to
> compare two strings ask yourself whether case-sensitive or
> case-insensitive is what you need. Have no inclination to prefer one type
> of comparison to the other. Problem solved. Bloat avoided.
> 
> 
> Creating specific types of strings that carry with them data on how they
> are to be interpreted is over-engineering, solving a problem that doesn't
> exist.

I don't know that it's over-engineering. I expect that there _are_ cases where 
it makes perfect sense. However, in the general case, I do think that it's 
overkill. std.string.icmp() deals with most cases where you need case-
insensitive comparison, but what if you really do need it everywhere as in 
Nick's case? Or what about cases like associative arrays, which you can't give a 
comparison function to (it has to be built into the type)? I don't think that 
the cost of the comparison here is really the issue. If that's all you need, 
then there's icmp(). It's when you need the same comparison _everywhere_ that it 
matters.

I don't know if this is worthwhile having in Phobos or not, but it might be. It 
definitely seems to me that in the general case, this sort of solution should not 
be used but that there are definitely cases where it would be extremely useful 
and get a rid of a host of potential problems.

Now, I do wonder if perhaps this idea should be generalized to any type and/or a 
given binary predicate to test for equality rather than making it specific to 
strings and case-insensitive comparison. The issue here (in the general sense) 
is that you want to wrap a type so that it will use a specialized comparison 
function everywhere, and that seems like it should be highly generalizable, 
though doing it right may require alias this, which _is_ rather buggy at the 
moment. Still, it would seem to me to be worthwhile to consider how it could 
and/or should be generalized.

- Jonathan M Davis