standard ranges

[Timon Gehr]

On 06/27/2012 11:11 PM, Steven Schveighoffer wrote:
> On Wed, 27 Jun 2012 16:55:49 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 06/27/2012 10:22 PM, Steven Schveighoffer wrote:
>>> On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr <timon.gehr at gmx.ch>
>>> wrote:
>>>
>>>> There is no reason for anyone to be confused about this endlessly. It
>>>> is simple to understand. Furthermore, think about the implications of a
>>>> library-defined string type: it just introduces the problem of what the
>>>> type of built-in string literals should be. This would cause endless
>>>> pain with type deduction, ifti, string mixins, ... A library-defined
>>>> string type cannot be a full string type. Pretending that it can has no
>>>> value.
>>>
>>> Default type of the literal should be the library type.
>>
>> Then it is not a library type, but a built-in type. Are you planning to
>> inject a dependency on Phobos into the compiler?
>
> No, druntime, and include minimal utf support. We do the same thing with
> AssociativeArray.
>

In this case it is misleading to call it a library type.

>>> If you want immutable(char)[], use "abc".codeunits or equivalent.
>>>
>>
>> I really don't want to type .codeunits, but I want to use
>> immutable(char)[] everywhere. This 'library type' is just an interface
>> change that makes writing nice and efficient code a kludge.
>
> When most string functions take strings, why would you want to use
> immutable(char)[] everywhere?
>

Because the proposed 'string' interface is inconvenient to use and 
useless. It is a struct with one data member and no additionally
maintained invariant, and it strictly narrows the essential parts of
the interface to the data that is reachable without a large typing
overhead. immutable(char)[] supports exactly the operations I usually
need. Maybe I'm not representative.

>>> Of course, it should by default work as a zero-terminated char * for C
>>> compatibility.
>>>
>>> The current situation is not simple to understand.
>>
>> It is simple, even if not immediately obvious. It does not have to be
>> immediately obvious without explanation. It needs to be convenient.
>
> Try sorting an array of ascii characters.
>

auto asciitext = cast(ubyte[])"I am ascii text";
sort(asciitext);


>>> Generic code that accepts arrays has to special-case narrow-width
>>> strings if you plan to
>>> use phobos with them in some cases. That is a horrible situation.
>>>
>>
>> Generic code accepts ranges, not arrays. All necessary (or maybe
>> unnecessary, I don't know) special casing is already done for you in
>> Phobos. The _only_ thing that is problematic is the inconsistent
>> 'foreach' behaviour.
>
> Plenty of generic code specializes on arrays.
>

Ok, point taken. But plenty of generic code then specializes on
strings as well. Would the net gain be so huge? There is also always
the option of just not passing strings to some helper template function
you defined.

There are multiple valid contradictory considerations on the topic, but
I have found the current way of dealing with strings very pleasant.

>>>> alias immutable(char)[] string is just fine.
>>>
>>> That is technically fine, but if phobos wants to treat immutable(char)[]
>>> as something other than an array, it is not fine.
>>>
>>> -Steve
>>
>> Phobos does not treat immutable(char)[] as something other than an
>> array. It does not treat all arrays uniformly though.
>
> It certainly does. An array by definition is a random-access range. It
> does not treat strings as random access ranges.
>
> -Steve

You are right about the random-access part, but the definition of an
array does not depend on the 'range' concept.