Gabriel Scherer

Some context (which will be obvious to Alain and Léo, but may help other people): Frédéric's proposal is in the line of the previous work by Pierre Chambart and Grégoire...

Indeed! ``` val f : [%auto : location] -> unit ```

Indeed, I think extension/attributes syntax can be a good surface syntax for ad-hoc features that are seen as part of the compiler implementation rather than the programming language itself. It...

Two remarks: - I voluntarily used `[%auto : location]` rather than `[%location]`, because I thought this could be a generic syntax for other things `auto`matically derived by the compiler (the...

I was thinking from a user point of view: having `[%ocaml.auto.eval ]` in the type means that the function will behave exactly as if, whenever the usual optional-parameter argument decides...

The explicit presence of the "optional argument" syntax is interesting, but this can also be achieved with extensions (also, you should give an example of the function-definition syntax, not just...

What's giving me pause with this PR is that it opens a can of worms. Sure, automatically-inferred locations are simple and easy to specify, but then users also want automatically-inferred...

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.

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...

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...