[EMAIL PROTECTED] (Ludovic Courtès) writes: > Marius Vollmer <[EMAIL PROTECTED]> writes: > >> Well, my current plans are to get us Unicode support by having three >> kinds of strings, with three widths (8, 16 and 32 bits, of course). >> But they are not very concrete. I am not thinking about using >> wchar_t. > > Because of its potential greediness in terms of memory consumption?
Yes, but mostly because I think the type is not really an important ingredient when using Unicode exclusively, since we know concretely what we want and don't need to rely on wchar_t as a portability aid. (There will of course be functions to convert Guile strings into wchar_t arrays.) One of the goals of moving SRFI 13 and 14 into the core was to discourage people from relying on the internal representation of strings. This means that this internal representation can be changed more easily, for example, to a multibyte encoding or to use splay trees, etc. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
