On 16/10/2010 20:51, Andrei Alexandrescu wrote:
On 10/16/2010 01:39 PM, Steven Schveighoffer wrote:
I suggest wrapping a char[] or wchar[] (of all constancies) with a
special range that imposes the restrictions.
I did so. It was called byDchar and it would accept a string type. It
sucked.
char[] and wchar[] are special. They embed their UTF affiliation in
their type. I don't think we should make a wash of all that by handling
them as arrays. They are not arrays.
Andrei
"They are not arrays."? So why are they arrays then? :3
Sorry, what I mean is: so we agree that char[] and wchar[] are special.
Unlike *all other arrays*, there are restrictions to what you can assign
to each element of the array. So conceptually they are not arrays, but
in the type system they are very much arrays. (or described
alternatively: implemented with arrays).
Isn't this a clear sign that what currently is char[] and wchar[] (=
UTF-8 and UTF-16 encoded strings) should not be arrays, but instead a
struct which would correctly represents the semantics and contracts of
char[] and wchar[]? Let me clarify what I'm suggesting:
* char[] and wchar[] would be just arrays of char's and wchar's,
completely orthogonal with other arrays types, no restrictions on
assignment, no further contracts.
* UTF-8 and UTF-16 encoded strings would have their own struct-based
type, lets called them string and wstring, which would likely use char[]
and wchar[] as the contents (but these fields would be internal), and
have whatever methods be appropriate, including opIndex.
* string literals would be of type string and wstring, not char[] and
wchar[].
* for consistency, probably this would be true for UTF-32 as well: we
would have a dstring, with dchar[] as the contents.
Problem solved. You're welcome. (as John Hodgeman would say)
No?
--
Bruno Medeiros - Software Engineer
