!standard  3.5.2(4/2)                             13-06-10    AC95-00251/00
!class confirmation 13-06-10
!status received no action 13-06-10
!status received 13-06-02
!subject Why Wide_Wide_Character?
!summary

!appendix

From: Robert Dewar
Sent: Sunday, June  2, 2013   10:23 AM

After typing Wide_Wide for the umpteenth time, I reflect on how on earth we came
to choose such bad names for these types. Character_16 and Character_32 would
have been SO much better.

Oh well, not a serious suggestion, just a rant I guess

***************************************************************

From: Erhard Ploedereder
Sent: Wednesday, June  5, 2013   5:38 PM

Well, we could have a first-class package

package Fixed_Size_Types is
  subtype uint8 is ...
  ...
  subtype char32 is ...

end FST;

for all the people in love with these types (of which there are very many). The
SE argument in favor of such a standardized package is that stupid bugs like

   subtype int8 is Integer range -127 ... +128 ;

will be prevented.

reasonably serious about it...

***************************************************************

From: Randy Brukardt
Sent: Friday, June  7, 2013  11:18 PM

> After typing Wide_Wide for the umpteenth time, I reflect on how on
> earth we came to choose such bad names for these types. Character_16
> and Character_32 would have been SO much better.
>
> Oh well, not a serious suggestion, just a rant I guess

I certainly have hated the name Wide_Wide_Character since the moment it was
introduced. I jokingly preferred "Really_Wide_Character" or "Giant_Character"
(you'll find some AARM notes that refer to it by one of these names); the
dictionary suggests "Broad_Character" or "Vast_Character". (I rather like the
latter today, as it has the right connotation and it's shorter and presumably
not so hard to type.) But too late now.

I suspect that the Ada 95 team used Wide_Character rather than Character_16 as
non-8 bit machines were still around in the early 1990's. And we probably still
thought of Size as referring to the allocation size rather than the abstract
(and useless) meaning assigned to it by Ada 95. For instance, on the U2200,
Character was a 9-bit type (necessary to avoid silly overpacking of type String
-- the machine had native 9-bit instructions but nothing native for 8-bits).
Wide_Character was an 18-bit type for the same reason, and the name Character_16
would have been weird at best.

Today, these considerations are gone and your suggestion would make sense for a
new language. But until we're creating Ada++ (sorry, Ada'Succ is lousy
marketing!), it's pretty much irrelevant.

***************************************************************

From: Randy Brukardt
Sent: Friday, June  7, 2013  11:24 PM

...
> Well, we could have a first-class package
>
> package Fixed_Size_Types is
>   subtype uint8 is ...
>   ...
>   subtype char32 is ...
>
> end FST;
>
> for all the people in love with these types (of which there are very
> many). The SE argument in favor of such a standardized package is that
> stupid bugs like
>
>    subtype int8 is Integer range -127 ... +128 ;
>
> will be prevented.
>
> reasonably serious about it...

We already have such a package: it's called Interfaces. It doesn't have
characters, but that's mainly because we don't have a good way to use types
other than the predefined String for string operations. Hopefully, Ada 2020 will
fix that, and perhaps such types could be added to Interfaces then.

P.S. You misnamed your package above, it should be:

   package Types_with_Lousy_Names_Inspired_by_Another_Language_with_a_Single_Character_Name is

:-) :-)

[The Ada language being pretty serious about avoiding abbreviations, I think
there would be a lot of resistance to introducing names like "Int" and "Char" in
anything language-defined.]

***************************************************************