Comment author: @xavierleroy

Note that it "works" also with normal variants:

type t = A of t | B of t | C
let f = function A B C -> ()

What do we gain by complicating the parser to reject this?

Comment author: @yallop

Well, it's a bit odd for constructor application to be right associative in patterns when expression application is left associative.

Oddness aside, bringing pattern and expression syntax into line could be used to simplify the parser, since the common bits could be factored out in some way, especially if we switch to menhir.

Even without refactoring, the change shouldn't complicate the parser. Something like the following should do it:

diff --git a/parsing/parser.mly b/parsing/parser.mly
index f444810..fbb0619 100644
--- a/parsing/parser.mly
+++ b/parsing/parser.mly
@@ -1733,3 +1733,3 @@ pattern_gen:
       { mkpat(Ppat_construct(mkrhs $1 1, Some $2)) }
-  | name_tag pattern %prec prec_constr_appl
+  | name_tag simple_pattern %prec prec_constr_appl
       { mkpat(Ppat_variant($1, Some $2)) }

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.

I ... actually like that feature. I use it occasionally (and I've seen it in the wild, so I'm not the only one). I'm not sure it's worth breaking existing code for this.

Agreed.