standard ranges

[Christophe Travert]

Timon Gehr , dans le message (digitalmars.D:170884), a écrit :
>> An I would say I am also entitle to say strings are not normal
>> ranges, since they define length, but have isLength as true,
> 
> hasLength as false.
Of course, my mistake.

> They define length, but it is not part of the range interface.
> 
> It is analogous to the following:
> [...]

I consider this bad design.

>> and define opIndex and opSlice,
> 
> [] and [..] operate on code units, but for a random access range as
> defined by Phobos, they would not.

A bidirectional range of dchar with additional methods of a random 
access range of char. That is what I call schizophrenic.

>> but are not RandomAccessRanges.
>>
>> The fact that isDynamicArray!(char[]) is true, but
>> isRandomAccessRange is not is just another aspect of the schizophrenia.
>> The behavior of a templated function on a string will depend on which
>> was used as a guard.
>>
> No, it won't.

Take the isRandomAccessRange specialization of an algorithm in Phobos, 
replace the guard by isDynamicArray, and you are very likely to change 
the behavior, if you do not simply break the function.

> When read carefully, the conclusion says that code compatibility is
> important only a couple sentences before it says that breaking code for
> the fun of it may be a good thing.

It was intended as a side-note, not a conclusion. Sorry for not being 
clear.

>> newcomers are troubled by this problem,  and I think it is important.
> 
> Newcomers sometimes become seasoned D programmers. Sometimes they know
> what Unicode is about even before that.

I knew what unicode was before coming to D. But, strings being arrays, I 
suspected myString.front would return the same as myString[0], i.e., a 
char, and that it was my job to make sure my algorithms were valid for 
UTF-8 encoding if I wanted to support it. Most of the time, in langage 
without such UTF-8 support, they are without much troubles. Code units 
matters more than code points most of the time.

> The language is consistent here. The library treats some language
> features specially. It is not the language that is "confusing". The
> whole reason to introduce the library behaviour is probably based on
> similar reasoning as given in your post.

OK, I should have said the standard library is inconsistent (with the 
langage).

> The special casing has not caused me any trouble, and sometimes it was 
> useful.

Of course, I can live with that.