standard ranges

[Steven Schveighoffer]

Sorry to resurrect this thread, I've been very absent from D, and am just  
now going through all these old posts.

On Wed, 27 Jun 2012 17:41:14 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 06/27/2012 11:11 PM, Steven Schveighoffer wrote:

>> 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.

What I mean is, the compiler does not define the structure of it.  It  
simply knows it exists, and expects a certain API for it.

The type itself is purely defined in the library, and could possibly be  
used directly as 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.

Most usages of strings are to concatenate them, print them, use them as  
keys, read them from a stream, etc.  None of this requires direct access  
to the data.  They can be treated as a nebulous type.

So maybe you are in the minority.  I don't really know.

>>>> 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.

I will respond to this in a different way.  This is the confusing part:

string x;
assert(!hasLength!string);
assert(!isRandomAccessRange!string);
auto len = x.length;
auto c = x[0]; // wtf?

It is *always* going to cause people to question isRandomAccessRange and  
hasLength because clearly a string has the purported properties needed to  
satisfy both.

>>>> 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.

The net gain is not in the reduction of specializations -- of course we  
will need specializations for strings because to do any less would make D  
extremely inefficient compared to other languages.

The gain is in the reduction of confusion.  We are asking our users "I  
know, I know, it's an array, but *please* pretend it's not! Don't listen  
to the compiler!"

And this is for a *BASIC* type of the language!

range.save() is the same thing.  It prevents nothing, and you have to take  
special care to avoid using basic operations (i.e. assign) and pretend  
they don't exist, even though they compile.  To me, that is worthless.  If  
a string does not support random access, then str[0] should not compile.  
period.

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

The range concept is notably more confusing with strings that are random  
access types but not random access ranges, even though they support all  
the properties needed for a random access range.

-Steve