On 10/14/13 1:09 AM, nickles wrote:
It's easy to state this, but - please - don't get sarcastical!
Thanks for making this point.
String handling in D follows two simple principles:
1. The support is a slice of code units (which often are immutable,
seeing as string is an alias for immutable(char)[]). Slice primitives
are readily accessible.
2. The standard library (and the foreach language construct) recognize
that arrays of code units are special and define bidirectional range
primitives on top of them. These are empty, save, front, back, popFront,
and popBack.
So for a string you may use the range primitives and related algorithms
to manipulate code points, or the slice primitives to manipulate code units.
This duality has been discussed in the past, and alternatives have
proposed (mainly gravitating around making one of the aspects explicit
rather than implicit). It is my opinion that a better solution exists
(in the form of making representation accessible only through a property
.rep). But the current design has "won" not only because it's the
existing one, but also because it has good simplicity and flexibility
advantages. At this point there is no question about changing the
semantics of existing constructs.
Andrei
