Leo White

> I'm not exactly sure how something generic like [this](https://github.com/ocaml/odoc/pull/303#discussion_r256563229) gets in the way of `mdx`-based alternatives Something like that seems fine. I was commenting on the proposal as written...

> [These samples](https://erratique.ch/software/cmdliner/doc/Cmdliner.html#examples) are full executables. Thanks that makes things clearer. So you have some literate programming within the `mli` files of a library. That's a reasonable use case. My...

I had thought that the compiler already collected these, but looking at the parser it seems not. I think that the attachment rules consistent with the existing ones would have...

I'm slightly surprised that we're going for: ```ocaml type t [@@hidden] ``` rather than: ```ocaml (** @hidden *) type t ``` which would be more consistent with things like: ```ocaml...

Could you also use other unicode for the symbols for debian, alpine etc.? I don't have any fonts that can display these letters in boxes symbols, and I imagine I...

> It might be better to stick with one keyword, and use a more general deletion syntax together with implicit in place of explicit: Yes something like that might be...

> Is there an alternative like open implicit Foo `open implicit Foo` was already supported before this patch.

Those are both good reasons, but my main motivation is to safely support patterns like inheritance. See section 3.3 of [the modular implicits paper](http://www.lpw25.net/ml2014.pdf) for some examples and explanation.

I believe that you could instead write something like: ```ocaml (* simple example *) implicit module List_eq {T:EQ} : EQ with type a = T.a list and type b =...

> This still does not satisfy the value restriction, or did I miss something? It should do. There are no function calls, uses of mutable fields, etc. so it should...