"Simon Marlow"
So let's aim for 6.6 to do it right, and design an abstract type for path names.
In this case it would be silly to *not* solve somehow the problem of filename encodings on Unix. Technically they are byte strings, and converting between them and Unicode strings is ambiguous. Usually they are in the locale's encoding, but it's not enforced. If filename is going to be a separate type, there is a chance to handle filenames which are not decodable in the locale's encoding, at least when they are just passed around and not converted to/from strings (e.g. read from directory contents and used to open the file). It's not clear how such filenames should be presented in strings. I think Gtk+ 2.6 introduced some functions for filename conversion because it used to be inconsistently reimplemented in various programs. For example there is a function which converts a filename to UTF-8 for display (Gtk+ uses UTF-8 internally); this function is not invertible. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/