std.algorithm.remove and principle of least astonishment

[KennyTM~]

On Nov 23, 10 01:40, Andrei Alexandrescu wrote:
> On 11/22/10 11:22 AM, Steven Schveighoffer wrote:
>> On Mon, 22 Nov 2010 12:07:55 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 11/22/10 9:37 AM, Steven Schveighoffer wrote:
>>>> On Sun, 21 Nov 2010 23:56:17 -0500, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>>> If you want to work with arrays, use a[0] to access the front, a[$ -
>>>>> 1] to access the back, and a = a[1 .. $] to chop off the first element
>>>>> of the array. It is not AT ALL natural to mix those with a.front,
>>>>> a.back etc. It is not - why? because std.range defines them with
>>>>> specific meanings for arrays in general and for arrays of characters
>>>>> in particular. If you submit to use std.range's abstraction, you
>>>>> submit to using it the way it is defined.
>>>>
>>>> I want to use char[] as an array. I want to sort the array, how do I do
>>>> this? (assume array.sort as a property is deprecated, as it should be)
>>>
>>> Why do you want to sort an array of char?
>>
>> You're dodging the question. You claim that if I want to use it as an
>> array, I use it as an array, if I want to use it as a range, use it as a
>> range. I'm simply pointing out why you can't use it as an array --
>> because phobos treats it as a bidirectional range, and you can't force
>> it to do what you want.
>
> Of course you can. After you were to admit that it makes next to no
> sense to sort an array of code units, I would have said "well if somehow
> you do imagine such a situation, you achieve that by saying what you
> means: cast the char[] to ubyte[] and sort that".
>

Right, and D3 should simply disable using char and wchar as an 
independent type, like void, since using a single code unit makes next 
to no sense either. As a side-effect, no one can complain containers of 
char and wchar doesn't work as expected because it simply won't compile. 
Then we can rightfully say char[] and wchar[] are special.

     char c = 'A';
     // error: A single code unit makes no sense. Make it a ubyte or 
dchar instead.
     int[char] d;
     // error: Indexing by a code unit makes no sense. Make it an 
int[ubyte] or int[dchar] instead.

:p

>> More points -- what about a redblacktree!(char)? Is that 'invalid'? I
>> mean, it's automatically sorted, so what should I do, throw an error if
>> you try to build one?
>
> No, it still has well-defined semantics. It just doesn't have much sense
> to it. Why would you use a redblacktree of char? Probably you want one
> of ubyte, so then why don't you say so?
>
>> Is an Array!char a string? What about an SList!char?
>
> Depends on how Array or SList are defined. D chose to convey char[] and
> wchar[] specific meaning revealing that they are sequences of code
> points, i.e. Unicode strings.
>
>> The thing is, *only* when one wants to create strings, does one want to
>> view the data type as a bidirectional string. When one wants to deal
>> with chars as an element of a container, I don't want to be restricted
>> to utf requirements.
>
> If you don't want to be restricted to utf requirements, use ubyte and
> ushort. You're saying "I want to use UTF code points without any
> associated UTF meaning".
>
>> FWIW, I deal in ASCII pretty much exclusively, so sorting an array of
>> char is not out of the question.
>
> Example?
>

One possible application could be (assume ASCII for a moment)

     pure bool slowIsAnagramOf(in char[] a, in char[] b) {
       auto c = a.dup, d = b.dup;
       sort(c);
       sort(d);
       return c == d;
     }

>> You might say "oh, well that's stupid!"
>> but then so is using the index operator on a char[] array, no? I see no
>> difference.
>
> There is a difference. Often in a loop you know the index at which a
> code point starts.
>
>> I'm going to drop out of this discussion in order to develop a viable
>> alternative to using arrays to represent strings. Then we can discuss
>> the merits/drawbacks of such a type. I think it will be simple to build.
>
> I think that's a great idea.
>
>
> Andrei