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