std.algorithm.remove and principle of least astonishment

[Michel Fortin]

On 2010-11-22 08:57:39 -0500, spir <denis.spir at gmail.com> said:

> On Mon, 22 Nov 2010 07:34:15 -0500
> Michel Fortin <michel.fortin at michelf.com> wrote:
> 
>> Just to add to the compexity: graphemes aren't always equivalent to
>> user-perceived characters either. Ligatures can contain more than one
>> user-perceived characters. If you're looking for the substring
>> "flourish" in a string, should it fail to match when it encounters
>> "flourish" just because of the "fl" (fl) ligature? On most
> Mac
>> applications it matches both thanks to sensible defaults in NSString's
>> search and comparison algorithms.
> 
> That's true. I guess you're thinking at the distinction between NFD/NFC "ca
> nonical forms" and NFKD/NFKC ones (so-called "compatibility").
> 
>> So perhaps we need yet another layer over graphemes to represent
>> user-perceived characters.
> 
> In my view, this is not the responsability of a general-purpose tool. I gue
> ss, but may be wrong, we are clearly entering the field of app logics and s
> emantics. These are for me _not_ general-purpose points (but builtin types
> & libraries often offer clearly non-general routines like one dealing with
> casing, or even less general: the set of ASCII letters). These issues would
>  have to be dealt with either by apps or by domain-specific libraries.

Is searching for a word in a text file less general purpose than 
searching for a specific combination of graphemes forming that word? 
That the implementation to get it right is quite complex doesn't make a 
tool less general purpose. The sole reason searching works this way in 
most Mac OS X (and iOS) applications is that Apple implemented it at 
the core of its string type and made it the default way of searching 
substrings and comparing strings. It's dubious whether even half of Mac 
applications would have implemented the thing correctly otherwise.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/