because it matches the de-facto behavior on earlier versions (which would be to raise a different exception)

What do you mean? Earlier versions fails only when the suffix is longer than the filename.

Since chop_suffix is likely to always be used in conjunction with check_suffix, I'm wondering whether it wouldn't be better to deprecate this function and expose:

  val chop_suffix_opt: string -> string -> string option

or even, using labels to avoid the confusion between the two string arguments:

  val chop_suffix_opt: suffix:string -> string -> string option

Earlier versions fails only when the suffix is longer than the filename.

Yes, that's what I meant--we should not change the behavior when the suffix is longer than the filename. If we changed chop_suffix to do nothing when the suffix is not present (such as when the suffix is longer than the filename), then code wirtten against 4.08 and ran against (e.g.) 4.07 would silently exhibit very surprising behavior.

Since chop_suffix is likely to always be used in conjunction with check_suffix, I'm wondering whether it wouldn't be better to deprecate this function and expose:

I have no opinion on this. I will implement whichever variant there is consensus for.

I would expect a name like check_and_chop_suffix or check_and_remove_suffix.

Updated.

• Typo sufffix -> suffix.

• The name of the function (check_...) suggests it is intended to be used on arbitrary inputs; if the suffix does not match, this is not a programmer error, and the function should thus not raise Invalid_argument.

• The current direction in stdlib is to prefer functions returning options over raising exceptions, and it is a canonical use of named arguments to avoid confusion between arguments of the same type when there is no natural ordering between them. So I propose:

val check_and_chop_suffix : suffix:string -> string -> string option

See also https://caml.inria.fr/mantis/view.php?id=7867 for a bug that could have been avoided with the option-returning function.

Superseded by #2125