New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re: [Caml-devel] Cacher constructeurs/etiquettes dans les types private (PR#3620) #3621
Comments
Comment author: administrator See also #3620 |
Comment author: administrator Cher Jacques, [...]
Bien sûr, c'est logique d'utiliser aussi le ... pour indiquer les
Bien sûr. Je voulais juste rappeler que ce champ pourrait être omis
Ce serait élégant d'avoir ce trait pour ce langage-ci aussi. Le Constructeur^.label qui me semble une généralisation -- |
These proposals for additions to the semantics of |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
There is no essential information, and we can resurrect this when we have a clearer plan. |
Original bug ID: 3621
Reporter: administrator
Status: acknowledged
Resolution: open
Priority: normal
Severity: feature
Category: typing
Related to: #3620
Bug description
Chers Alain et Pierre,
Une petite remarque: ces deux possibilités sont déjà disponibles pour
les types à rangée privés (variants polymorphes et objets).
Mais ça ne fait que rendre plus naturel de les avoir pour les types
privés originels.
Les types à rangée privés ne sont pas limités par l'ordre des
étiquettes/constructeurs, mais dans le cas ci-dessus cette limitation
ne semble pas être un problème.
Par rapport au problème de l'égalité structurelle, une solution serait
de reprendre la syntaxe des types à rangée:
type t = private {a: int; b: int; ..}
Comme ça on sait qu'il y a d'autres champs, qui peuvent intervenir
dans les comparaisons. D'un autre côté cette distinction peut polluer
les interfaces.
Je ne suis pas sûr de comprendre le "ni à la construction".
Dans l'exemple ci-dessus la question ne se pose pas puisque le
constructeur Foo est lui-même privé?
C'est en effet un propriété intéressante de la représentation des
types variants (pas possible avec les variants polymorphes). Ce qui ne
va pas sans me rappeler l'idée (jamais poussée) de nommer les
paramètres d'un type somme, comme dans un enregistrement.
type t = Foo of {a: string; b:int}
Mais je crois qu'il faudra garder ça pour un autre langage.
Jacques
The text was updated successfully, but these errors were encountered: