Continuing the discussion from Why is OCaml convention to use `type t = … `:
Are you sure the SML-like strategy of annotating the type doesn’t work in modern OCaml? I recently embraced using same constructors and field names where that’s meaningful. There was even an example on the forum recently I also follow, of using the same field name in records embedded in different constructors of the same variant datatype.
This assumes not using the principal typing flag.
To be honest, I don’t know, because I don’t write code that would rely on such a feature. All I know is when I started using caml-light in 1992, I came from SML and was surprised to find that overloading field names didn’t work. After a conversation with Pierre Weis I understood that the reason was that the original type Inference algorithm didn’t support it, because the goal was to never need type annotations in order to type check well-typed code.
To be honest, I agree with this goal and so even if extensions to the type checking algorithm today would allow for overloading a field names, I wouldn’t do it.
To paraphrase Pierre, your code is either well-typed or it isn’t, and no amount of type annotations can change that. To my mind that is an incredibly valuable property, and I would not give it up. Now interestingly, once you introduce adhoc polymorphism or modular implicits, you obviously can lose this property. But for code that doesn’t use adhoc polymorphism, this property is still valuable.
ETA: I should have said 'once you introduce modular implicits, depending on what sort you introduce, you might lose this property". I refer specifically to the sort of traits that Rust provides, where sometimes you must provide the type of the result of an overloaded trait/function, in order to select which trait implementation will be inferred.