I still believe this would be a useful addition to the language, in particular to facilitate the job of ppx rewriters that need to inject components for local use only.

• Do people agree on the usefulness of the addition?

• I'm not fully confident in how the non-escaping constraint is implemented in this PR. @garrigue : could you have a look?

• We need to discuss the user interface for the feature. I can see two directions. If the feature is only intended to be used by ppx rewriters, using an attribute (as currently) could be ok. If we want to advertise it for general use, one should perhaps introduce a specific syntax (and representation in the Parsetree). (But note that there are already "features" which impact type-checking and which are triggered by attributes.)

Do people agree on the usefulness of the addition?

I agree that it's useful to be able to introduce unexported declarations.

I don't like the approach of using attributes to change typing/scoping behaviour.

Over on #682 you said:

Yet another alternative would be to support only module private X = ..., which allows encoding open struct ... end as module private X = ... ;; open X (with the drawback of having to invent a module name).

I think the best option is to support open struct ... end directly, which would support the same use cases, but without the drawback you mention.

I think the best option is to support open struct ... end directly, which would support the same use cases, but without the drawback you mention.

Agreed. Well, I guess we should directly aim at supporting open <module_expr> then. This would be more regular, syntactically, and not more difficult (since this is equivalent to open struct include <module_expr> end). open Foo(Bar) and open (Foo : S) could be useful, for instance.

open (Foo : S) could be useful, for instance.

Yes! It would be much safer to declare the expected interface when opening a module.

@alainfrisch: @yallop and I have written a paper about it (submitted to OCaml Workshop this year so if you come we can talk more on Friday). Implementation is also done and there is a playground. However, the code still needs some polish.

Wow @objmagic nice job! Nice paper, and I love that the playground reflects it.

Ah, @yallop you could have mentioned this earlier in the discussion!

Closing this, as @objmagic and @yallop work subsumes the current proposal.