Que doit faire un caractère d'échappement si le caractère suivant n'a pas besoin d'être échappé?

Question

Une application sur laquelle je travaille comporte un champ dans lequel une chaîne peut être saisie. Les caractères spéciaux de la chaîne provoquent l'insertion de différentes choses lors de l'évaluation de la chaîne, mais ces caractères spéciaux peuvent être précédés d'un caractère d'échappement (une barre oblique inverse) qui provoque la sortie littérale du caractère spécial plutôt que sa signification particulière . Pensez-y comme semblable à une expression régulière: . correspond à n'importe quel caractère, mais \. correspond à un point.

Quelle est la chose la plus intuitive à se produire lorsque le caractère d'échappement est suivi par un caractère qui n'a pas besoin d'échapper? Par exemple, serait-il plus logique que:

1. Le caractère d'échappement « échappe » littéral comme lui-même: \f devient f (« un f échappé »)
2. Le caractère d'échappement n'est pas un caractère d'échappement à moins il est suivi d'un caractère spécial: \f reste comme \f
3. Erreur! Lève une exception car il est invalide d'avoir un caractère d'échappement n'échappant à rien

Tout cela est possible et à mon avis justifiable. Mais qui a plus de sens, et qui est déjà le plus commun dans d'autres langues?

Answer 1

Je voterais pour la première solution. Cela facilite la création de chaînes: si vous ne savez pas si un personnage a une signification particulière dans votre contexte, évitez-le. Ça ne fera pas mal.

Answer 2

En fin de compte, la bonne réponse n'est probablement pas indépendante de la langue. Dans Ada, je m'attendrais à l'option trois, car il s'agit principalement d'appliquer strictement des règles strictes. En Perl, je m'attendrais à l'option un ou deux, parce que c'est en général beaucoup plus permissif. Puisque je suis principalement un programmeur C++, je voterais pour l'option 4: organiser une fonction pour être appelée dans un tel cas. La séquence "défectueuse" lui est transmise en tant que paramètre, et on s'attend à retourner un résultat interprété ou à lancer une exception. S'il s'agissait d'une API Windows natif, je m'attendais à quelque chose de proche de la solution C++, seulement elle construirait une chaîne de fonctions, en commençant par la dernière ajoutée, et en descendant la chaîne jusqu'à une fonction soit retourné un résultat interprété, ou il est arrivé à la fin de la chaîne où la fonction par défaut serait lancer une exception.