[bitc-dev] String encoding, again
bklooste at gmail.com
Wed Mar 23 23:27:15 PDT 2011
Allows string to be programmer friendly and Ustring for indexing
performance. Why define the views ? Some string implementations may not
support direct indexing ie only vs higher levels or is GetUString8() ,
GetUString16() or GetUString32() regarded as a view ?
Question why not define Ustring as a vector /array ? This makes it clear
String should wrap or at least support Ustring
The vector is used for interop
From: bitc-dev-bounces at coyotos.org [mailto:bitc-dev-bounces at coyotos.org] On
Behalf Of Jonathan S. Shapiro
Sent: Thursday, March 24, 2011 1:20 PM
To: Discussions about the BitC language
Subject: Re: [bitc-dev] String encoding, again
In the interest of progress, I am going to concede defeat on the problem of
strings. In the interest of progress, I propose to adopt the following
* Instances of the BitC type String contains a sequence of Unicode
code points. This is a well-formedness constraint, and it is a requirement
that all string manipulation functions maintain it.
* The internal encoding of a String is unspecified, but will be
selected by the implementation to optimize for space.
* Indexing operations on Strings operate in no worse than linear time.
* Indexing operations will be provided on Strings providing views
corresponding to ucs1, ucs2, and ucs4 code units.
* Instances of the BitC type UString likewise contain a sequence of
Unicode code points.
* A UString is indexed only on code points.
* A UString is required to provide constant-time indexing on code
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev