standard ranges
Christophe Travert
travert at phare.normalesup.org
Thu Jun 28 02:28:52 PDT 2012
Jonathan M Davis , dans le message (digitalmars.D:170872), a écrit :
> On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
>> "Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
>> > completely consistent with regards to how it treats strings. The _only_
>> > inconsintencies are between the language and the library - namely how
>> > foreach iterates on code units by default and the fact that while the
>> > language defines length, slicing, and random-access operations for
>> > strings, the library effectively does not consider strings to have them.
>
>> char[] is not treated as an array by the library
>
> Phobos _does_ treat char[] as an array. isDynamicArray!(char[]) is true, and
> char[] works with the functions in std.array. It's just that they're all
> special-cased appropriately to handle narrow strings properly. What it doesn't
> do is treat char[] as a range of char.
>
>> and is not treated as a RandomAccessRange.
All arrays are treated as RandomAccessRanges, except for char[] and
wchar[]. So I think I am entitled to say that strings are not treated as
arrays. An I would say I am also entitle to say strings are not normal
ranges, since they define length, but have isLength as true, and define
opIndex and opSlice, 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.
>
> Which is what I already said.
>
>> That is a second inconsistency, and it would be avoided is string were a
> struct.
>
> No, it wouldn't. It is _impossible_ to implement length, slicing, and indexing
> for UTF-8 and UTF-16 strings in O(1). Whether you're using an array or a
> struct to represent them is irrelevant. And if you can't do those operations
> in O(1), then they can't be random access ranges.
I never said strings should support length and slicing. I even said
they should not. foreach is inconsistent with the way strings are
treated in phobos, but opIndex, opSlice and length, are inconsistent to.
string[0] and string.front do not even return the same....
Please read my post a little bit more carefully before
answering them.
About the rest of your post, I basically say the same as you in shorter
terms, except that I am in favor of changing things (but I didn't even
said they should be changed in my conclusion).
newcomers are troubled by this problem, and I think it is important.
They will make mistakes when using both array and range functions on
strings in the same algorithm, or when using array functions without
knowing about utf8 encoding issues (the fact that array functions are
also valid range functions if not for strings does not help). But I also
think experienced programmers can be affected, because of inattention,
reusing codes written by inexperienced programmers, or inappropriate
template guards usage.
As a more general comment, I think having a consistent langage is a very
important goal to achieve when designing a langage. It makes everything
simpler, from langage design to user through compiler and library
development. It may not be too late for D.
--
Christophe
More information about the Digitalmars-d
mailing list