On 06/27/2012 11:11 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 16:55:49 -0400, Timon Gehr <[email protected]> wrote:
On 06/27/2012 10:22 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr <[email protected]>
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.
