Re: Jeux de caractères, notamment UT F-8

Le 23 juin 2021 à 23:17, Thomas De Contes via Ada-france a écrit :

> S'il était permis d'appliquer cet aspect String_Literal à Ada.Strings.UTF_Encoding.UTF_8_String,

> ... et je serais heureux ! :-)
> 
> Est il envisageable d'arriver à ça dans une prochaine version du langage ?
> Peut-être dans une "correction technique" intermédiaire ? Voire dans la toute prochaine version, s'il n'est pas encore trop tard (soyons fou) ?

J'espérais un peu, mais je m'attendais plutôt à un retour négatif en m'expliquant pourquoi ce que je proposais n'était pas possible.


Par contre là je viens d'avoir une idée, qui me semble à la fois très simple et sans inconvénient pour personne (j'espère que je ne me trompe pas).

J'espère qu'il n'est pas encore trop tard pour l'intégrer à la norme en cours qui n'est pas encore finalisée,
et je me dépêche d'écrire ça avant de partir en vacances, au cas où la date limite se situerais pendant mes vacances.
J'espère que vous m'excuserez si à certains moments je manque de rigueur.



Allons droit au but :
Ma proposition, c'est ajouter dans Ada.Characters.Handling :

subtype ISO_646_String is String
   with Dynamic_Predicate => Is_ISO_646 (ISO_646_String);

(Pas sur que ça soit bien écrit, mais au pire on peut remettre l'intervalle en dur :
   with Dynamic_Predicate => (for all E of ISO_646_String => E in Character'Val(0) .. Character'Val(127)); )



(Je me suis inspiré de Ada.Locales.Language_Code)


La raison est que :
- D'après moi les 2 jeux de caractères / encodages les plus importants sont ASCII et UTF-8.
- ASCII pour plein de raisons, mais notamment parce que :

Gagner du temps en faisant des conversions implicites entre Standard.String et Ada.Strings.UTF_Encoding.UTF_8_String, ca marche à la condition expresse de manipuler exclusivement de l'ASCII :
Puisqu'il n'existe pas de caractère Unicode non-ASCII qui soit encodé en UTF-8 sur 1 seul octet, il n'existe pas de chaine qui contienne un caractère non-ASCII et qui soit codée pareil en Latin-1 et en UTF-8.

Ma proposition permettrais de déclarer des variables de type ISO_646_String, ça me parait beaucoup plus simple et beaucoup plus sur que de faire un usage explicite abondant de Is_ISO_646.

Il reste le cas des fonctions qui prennent un UTF_8_String et qu'on appelle directement avec un littéral, avec lequel il faudra rester vigilant.
Mais on peut probablement s'en tirer avec quelque chose du genre Fonction(ISO_646_String'("literal")) ?
(Allez faire le même test avec Is_ISO_646 sans multiplier les lignes de code ;-) )



En passant on pourrais faire la même chose pour Ada.Strings.UTF_Encoding.UTF_8_String, en ajoutant une fonction Is_UTF_8.
(Il me semble que ça ne serais pas énormément plus couteux, puisque sur chaque octet on n'a que les 2 1ers bits à vérifier.)
Mais ça ne résoudrait pas tous les problèmes, puisque toutes les chaines UTF-8 valides sont aussi des chaines Latin-1 valides.

(Même si la disponibilité en standard de Is_UTF_8 serait bienvenue, tout ce paragraphe est secondaire par rapport à l'objet de ce message.)


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france