Comment author: @gasche

How would having a different behavior just for arrays make sense?

Comment author: @lefessan

Ok, let's come back to the origin: I want to generate a huge set of symbolic names for values coming from an array. Of course, I can do:

let foo = t.(0)
let bar = t.(1)
etc.

but I think it would be much nicer to have:

let [| foo; bar; ... |] = generate_values ...

especially as the users will probably use this idiom a lot in their programs.

At the same time, I don't want to disable warnings for standard pattern-matching, so I am proposing this solution, in case somebody else would find that they have the same problem and would be interested with the same solution.

Of course, I am interested in any other solution, or to generalize to some other types than arrays.

By the way, I am not fond of the solution that I am currently using:
let (foo, bar, ...) = Obj.magic (generate_values ...)

Comment author: @gasche

At the same time, I don't want to disable warnings for standard pattern-matching, so I am proposing this solution, in case somebody else would find that they have the same problem and would be interested with the same solution.

I once had the same issue for lists:

let [foo;bar;baz] = List.map wrap [foo'; bar'; baz']

my solution was to develop a syntax extension (uploaded here, courtesy of 2007)
http://gallium.inria.fr/~scherer/tmp/refutable/

I think a pragma to locally-disable refutability warning would be much, much nicer than a type-directed approach. That's at arm's length in Alain's extension_points branch.

By the way, I am not fond of the solution that I am currently using:
let (foo, bar, ...) = Obj.magic (generate_values ...)

Indeed, it's the ugliest code I've seen today yet :-)

Comment author: @xavierleroy

(2) raise Exception: Invalid_argument "index out of bounds"
instead of Match_failure, for the specific case (let [| ... |] = ... ).

This would be backward-incompatible. All this breakage and effort for a minor stylistic issue in generated code. I move to close/no-change-required.

Comment author: @lefessan

This would be backward-incompatible.

For me, anybody who would put a "try ... with Assert_failure ->" around a non-exhaustive "let" instead of using "match with" in the first place would deserve to see its code broken...

All this breakage and effort for a minor stylistic issue in generated code.

It is not generated code, but an idiom when creating WxWidgets applications in OCaml, users have to define lots of symbolic variables for widgets identifiers, and writting list of "let toto_id = t.(..)" is both tiring, unreadable and error-prone. I was just looking for a way to make it nicer to read.

I think a pragma to locally-disable refutability warning would be much, much nicer than a type-directed approach. That's at arm's length in Alain's extension_points branch.

Sounds like a good idea !

Comment author: @xavierleroy

For me, anybody who would put a "try ... with Assert_failure ->" around a non-exhaustive "let" instead of using "match with" in the first place would deserve to see its code broken...

Agreed, but it's an incompatible change nonetheless, and as a matter of policy we don't do this unless there are really strong reasons.

(And no open bugs for a forthcoming release, which is definitely not the case right now. Go back triaging!)

I think a pragma to locally-disable refutability warning would be much, much nicer than a type-directed approach. That's at arm's length in Alain's extension_points branch.

Indeed. So, it's "resolved/suspended" until we make progress on the "extension points" approach.