So there's two bugs here:

1. The wrong argument number.

Notice the other syntax:

numfmt_format(NumberFormatter $formatter, int|float $num, int $type = NumberFormatter::TYPE_DEFAULT): string|false

Internally, class methods look a lot like regular functions that happen to take the "this" object as the first argument, and the procedural syntax for numfmt_format intentionally mirrors that fact. So when it says argument 3 it does mean the $type and it's not noticing that you used the OOP syntax.

Given this procedural/OOP stuff is a common setup, I assume this "is it argument 2 or 3?" problem has a standard solution.

2. TYPE_CURRENCY isn't supported.

This is likely deliberate because there's a formatCurrency method available. It takes a special $currency argument so that functionality can't simply be added to format.

IMO this needs two fixes: one that PHP detects TYPE_CURRENCY and then tells you that you need to use formatCurrency instead, then another for the docs.

glad someone agrees that something is amiss. both of the proposed fixes sound like the correct direction.

just for full vision the reason i did what i did the way i did, was it seemed like numberformatter could be told to init with a locale and desired formatting. and indeed i noticed the formatCurrency method, and more specifically, that the format method took a type.

this suggested to me that i should initialise one numberformatter global to my app instance, using the user's preferences, and for consistency sake across all my various calls, i elected to only use format with type currency so that it looked like all the other calls to format this and that and those. the final assumption i made was that numberformatter as en_US would default to USD, which would then make format(value, CURRENCY), seem reasonable.

Given this procedural/OOP stuff is a common setup, I assume this "is it argument 2 or 3?" problem has a standard solution.

It seems so far it has not. In theory it could be done by modifying the zend_argument*error() functions, but that would be a BC break, since external extensions may already cater to that, like for example, transliterator_transliterate():

So we likely need to handle the individual calls.

IMO this needs two fixes: one that PHP detects TYPE_CURRENCY and then tells you that you need to use formatCurrency instead, then another for the docs.

I would go with a doc fix only, but given that it is documented to support any TYPE_*, an explicit error message may be reasonable.