Re: [AD] Proposal to kill non-UTF-8 support

["Matthew Smith" <matt@xxxxxxxxxx>]

> The nice thing about UTF-8 is that conversions are not needed
> for ASCII strings, which are many. It can be very difficult
> to decide whether something should be converted or not. UTF-8
> bypasses this problem easily.

This is fair enough for ASCII->UTF-8, but not the other way around.

> Cases like this are: if you get a filename, should it be in
> ASCII or not ? When ? When you display it ? When you pass it
> to and forth to the OS ? What about code that needs to find
> data in it ? This is a real pain to deal with, especially in
> plain C, where it is not easy to have a specific class for
> i18n strings that you can swap with std::string. Of course,
> going this easy way means your code isn't really correct, but
> it is more robust.

But this has to be dealt with, because some OSs will choke on non-ASCII, and
others require it, e.g. because all the filenames are chinese.
Perhaps there should be seperate conversion regimens for display and OS
calls.
Maybe newer versions of gcc will accept UTF-8 names and string literals,
which will vastly increase their usage.

I don't know how this affects the implementation, but as an API idea how
about
al_ustr*  - UTF-8
al_wstr* - UCS-2 (windows version)
al_lstr*  - UTF-32
al_vstr*  - functions which take extra parameters for coding of source and
destination, and have void* data types.

Maybe a version of fopen() could include a spec for the format used in a
particular file.

That's enough hot air from me, none of my ideas have ever panned out yet :)
I nearly deleted this but it might be food for thought.

Matt