On Wed, Mar 23, 2011 at 12:42 AM, William ML Leslie < [email protected]> wrote:
> On 22 March 2011 12:26, Jonathan S. Shapiro <[email protected]> wrote: > > So here, concretely, is what I'm contemplating: > > > > 1. Strings will have unspecified internal representation, but well-formed > > strings will contain code points, not code units. > > Where by contain, you mean what, exactly? yield when iterated? yield > when indexed? > That's the key question. Ignoring what operations we will define for a moment, I suppose what I mean is that every string shall have a valid interpretation as a sequence of code points, and that operations in the BitC library that produce or compose strings shall preserve this property. In particular, this means that a StringBuilder-analogue that appends (e.g.) UCS16 units has states in which its "pending" String is not well-formed, and a call to .asString() in one of those states must throw an exception. > Did we ever determine a case for non-typesafe (ie, in terms of code > units rather than code points) indexing? > We clearly have to support that, mainly for interop reasons. There is no safety failure in providing *read* access at the granularity of code units. That help any? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
