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.

How would such annotation work on abstract types ? It seems like it would be incomplete by nature, making it not very useful.

I believe that the proposal is precisely to be able to add this annotation on an abstract type in a signature, like ocaml.immediate, to properly deal with abstraction boundaries.

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.

We are in the process of revamping the implementation of immediate, see #10041. I think that other "type properties" like the one proposed here would be easier to add after that work is complete.

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.

@gasche , do you still think we should revisit the issue now that we have revamped the handling of immediate?

I think that we actually haven't revamped the handling of immediates, none of the PR attempting to do it have been merged -- for a mix of not-so-good and some good reasons.

If someone wants to implement the current feature, I think that this is a reasonable thing to do without waiting for any other change.

(what follows is a brain dump of what I remember on this question)

The question is where in the typechecker structures we want to store kind information on abstract types. #10041 was suggesting that the current way we are doing it is not the best one, and proposing a different approach. I also needed to answer this question in my own (still unmerged) work on constructor unboxing, and this is the same question here. The Jane Street fork also touches this for unboxed types layouts, and I hoped that we could all converge to a single good way to do this, merge it upstream (independently of those features), with a record type at the right place that we can grow it independently without too much conflicts.

But then the Jane Street people realized that they weren't sure which approach was best, and (if I understand correctly) they went back from what #10041 proposed to something closer to what we currently have upstream -- I'm not sure. But we still don't have this record type to which anyone can just easily add this information, so there is no obvious way to implement it without conflicting with everyone else that has unmerged changes doing something like this.