Re: C and C++, promotion, stabilization, migrationFor embedded

On 8/27/2024 8:54 AM, Simon Clubley wrote:

On 2024-08-25, Dave Froble <davef@tsoft-inc.com> wrote:

On 8/23/2024 7:41 PM, Lawrence D'Oliveiro wrote:

On Fri, 23 Aug 2024 19:34:18 -0400, Arne Vajhøj wrote:

UTF-8 in file names, in usernames, in logicals, in identifiers and in
programs/scripts: not really needed.

>
I would say these are needed.

>
I have to ask, why?
>
All the objects mentioned by Arne are in simple terms 'tokens' to represent some
object.  I see no reason for the elements in such tokens to be more complex than
required.  Perhaps a bit more complex than the "A", "B", "C", etc of WEENDOZE
disk names.  But needing everything every user might dream up?  I don't see the
benefit.  Other than perhaps stubbornness and ego of some particular user.  It
just defies the KISS principal, which I find to be useful.

 If I had said "that there was no need for UTF-8 because we will just have
people use British English from now on", then how do you think that would
have come across ?
 Yet you have just done the same David. You have just said that if it is
not used in US English then it is not important and the rest of the world
should just learn to restrict itself to US ASCII characters in their use
of filenames, etc.

There is a difference between what end users see and the underlying
infrastructure that enables them to see it.
The end users should be able to see all sort of languages.
But end users are not doing $ SET DEF and $ TYPE anymore.
They should not care about directory and file names.
Hoff has stated a few times that VMS actually has implemented
UTF-8 support in filenames. Probably more than 20 years ago.
Anyone been using tat feature in the last 20 years?
I don't think so. Which hints about the value.
VMS is in dire need for something that makes conversions
between DECMCS/ISO-8859-1 and UTF-8 easy for the traditional
native languages.
But UTF-8 support in file names, usernames, logicals, program
identifiers is mostly a gimmick.
Arne