On a suggestion by @Octachron, local open is now systematically disallowed in constructor arguments for consistency: the change proposed by @let-def would allow Foo of M.(r) * M.(t) but reject Foo of M.(r), and now both are rejected.

Personally, I'm happy with allowing type t = Foo of M.(bar * baz) and interpreting it as a single tuple argument, since I think of M.(...) as enhanced parentheses.

I don't necessarily disagree. On the other hand, I see the following arguments in favor of restricting:

• If unsure, restrict more, it is easy to allow later.
• If people make the wrong guess that of M.(r * s * t) has several arguments -- what would be written M.(r and s and t) in revised syntax -- then it is very hard for them to realize their mistake, and they silently get a worse value representation. In the direction, if you are surprised by a syntax error but really want to use the local-open syntax as a single argument, then writing (M.(r * s * t)) is ugly but low-pain.

Personally, I'm happy with allowing type t = Foo of M.(bar * baz) and interpreting it as a single tuple argument, since I think of M.(...) as enhanced parentheses.

if that's the case, how would you express multiple constructor args with a local open?

@hyphenrf note that there isn't currently a syntax to allow a local open around several arguments. (And I'm quite sure that it would be a bad idea to use of M.(... * ... * ...) for this.).

One can of course use

open struct
  open M
  type t = ...
end

at the level of one or several structure items.

if that's the case, how would you express multiple constructor args with a local open?

I don't think it matters if it's not possible to express that with a single local open; there are lots of things local opens can't do. I think it's more important to have a uniform rule, like "M.(te) can go anywhere a type expression can go".

like "M.(te) can go anywhere a type expression can go"

I would argue that rule is respected either way here, as the debate is really about whether the argument to a constructor is a single type expression or a sequence of type expressions separated by *. I think it is the latter hence why I think it should be an error, but the other position is also consistent.

Disallowing T of M.(x) * M.(y), as the PR currently does, seems unambiguously inconsistent with the rule.

To recap, there are three choices:

1. trunk: allow of M.(foo) and of M.(a) * M.(b)
   justification: M.(ty) is a single type expression (despite the potential for confusion for M.(a * b))
2. the first iteration of this PR: disallow of M.(foo) but allow of M.(a) * M.(b)
   justification: of M.(a * b) could be perceived as ambiguous, so we reject it as a special case
3. the second/current iteration of this PR: disallow both of M.(foo) and of M.(a) * M.(b)
   justification: to avoid any perceived ambiguity, constructor arguments cannot start with a toplevel local-open

I find (1) and (3) both conceptually simpler than (2), and the grammar is also simpler.

In all cases of (M.(foo)) is allowed, because this is clearly unambiguous (it is an explicitly-disambiguated form). There is no corresponding explicit-disambiguation for the other interpretation. (I think M.(Foo of ...) would be the most natural syntactic choice.)

I think that it may now too late to improve on this, local open in types has shipped without it and we haven't managed to build a consensus to restrict it here. Closing.