Comment author: @garrigue

This is the expected behavior: in a class type, a free type variable in a method is generalized, as otherwise the class type would be invalid, hence the meaning for M3.
However, if the type variable already appears in a constraint (M1) or if an explicit polymorphic type is given (M2), this is not the case.

This behavior was chosen to simplify the writing of polymorphic methods, particularly when there are row types involved.

But you have a point here: since in M3 the type of self is captured by a type variable, and as a result the type where 'a is not quantified would still be valid,, it would be more natural to have the same behavior as M1 and M2. In theory, this is a change in behavior, but in practice I would not expect this to break anything. We would still need a clear criterion for that.

Comment author: @fpottier

Hi Jacques.
Yes, my thinking is that if the class is parameterized over the type of self, then the equality constraint 'self = < list of all methods; .. > should be implicitly added to the class type. That should allow the method types to contain free type variables, without creating problems.

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.

@fpottier I don't see why it should be so. Currently the criterion is that any type variable in a method type that is not explicitly bound in a class parameter or a contraint is interpreted as universal in the method type. This seems a simple enough criterion. It would be strange that just having the type of self appear in a parameter should change this behaviour, and there is nothing wrong in having polymorphic methods appear in the type of self.

I am not suggesting any change. Actually, the behavior that surprised me at the time is documented in the manual ("The polymorphism may be left implicit in public method specifications: any type variable which is not bound to a class parameter and does not appear elsewhere inside the class specification will be assumed to be universal, and made polymorphic in the resulting method type. Writing an explicit polymorphic type will disable this behaviour."). But, because the manual does not contain any examples, it is actually fairly difficult to understand what it means...

So you are suggesting to add examples to the manual. Would you be willing to submit them as a PR?

I wrote about some of my findings in the visitors manual (Section 4), but I wouldn't have time at the moment to turn that into a PR, sorry.

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.

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.