Ainsi les cas exceptionnels qui ont besoin de sortir de ces bornes doivent coder leur propre fonction avec un test sur la valeur de l'entrée.
Non.
Si OCaml disposait de la notion de sous types (contraints) alors il disposerait de deux fonctions shr. L'une utilisant ce type contraint garantirait l'efficacité optimale et l'autre (qui ferait le test) pour assurer la cohérence de l'arithmétique pour tout valeur naturelle de l'argument.
Il n'y aurait donc la vérification à faire que lorsque cela est nécessaire pour le développeur. On y gagnerait sur tous les plans. C'est ce que j'expliquais dans un ancien post.
D'autre part une signature de la fonction shr avec deux int en entrée et un int en sortie est étrange puisque le second paramètre devrait être un entier naturel (en tout cas sûrement pas un modulaire, qui n'a aucune signification arithmétique cohérente). Du coup on se retrouve avec une fonction qui a des comportements indéfinis en fonction de certaines valeurs des paramètres ce qui est source de bug (la preuve avec mes étudiants). Là tu peux avoir des résultats qui ne lèvent aucune exception au runtime ni aucun avertissement à la compilation.
[^] # Re: Du haut niveau pour gérer correctement du bas niveau
Posté par snowball (site web personnel) . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 1.
Non.
Si OCaml disposait de la notion de sous types (contraints) alors il disposerait de deux fonctions shr. L'une utilisant ce type contraint garantirait l'efficacité optimale et l'autre (qui ferait le test) pour assurer la cohérence de l'arithmétique pour tout valeur naturelle de l'argument.
Il n'y aurait donc la vérification à faire que lorsque cela est nécessaire pour le développeur. On y gagnerait sur tous les plans. C'est ce que j'expliquais dans un ancien post.
D'autre part une signature de la fonction shr avec deux int en entrée et un int en sortie est étrange puisque le second paramètre devrait être un entier naturel (en tout cas sûrement pas un modulaire, qui n'a aucune signification arithmétique cohérente). Du coup on se retrouve avec une fonction qui a des comportements indéfinis en fonction de certaines valeurs des paramètres ce qui est source de bug (la preuve avec mes étudiants). Là tu peux avoir des résultats qui ne lèvent aucune exception au runtime ni aucun avertissement à la compilation.