Indeed, StringCases
does not have an operator form in 10.0.1. The documentation and usage message appear to be in error.
StringCases
does not appear on the list TypeSystem`$OperatorForms
-- although that is by no means conclusive as discussed here. I would argue that it should have an operator form, in symmetry with Cases
. In any event, there is a bug here either in the documentation or in the implementation of StringCases
.
Note that operator forms for functions like StringCases
and Cases
pose some problems. For StringCases
, there are two arguments that could credibly be curried: the pattern and the occurrence count. But if the caller specifies two arguments, it is ambiguous whether it means StringCases[patt, n]
or StringCases["string", patt]
. Such are the pitfalls of idiomatic currying when the arguments lists were not designed with currying in mind.
None of this reasoning conclusively argues against the single argument operator form which has reasonably unambiguous meaning. Further more, WRI have already elected to give Cases
an operator form even though the currying situation there is even worse, with three arguments that could be curried (pattern/rule, levelspec, occurrence count).