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
