The watchlist expiry is slightly different than some others in that a blank value means "don't change", not "indefinite". Our refactoring should keep in this mind as other APIs unrelated to watchlisting (such as the userrights API) treat blank/null expiries differently.

That probably doesn't matter for this task. A TypeDef for parsing expiries should only concern itself with parsing actual user input, and the empty string should probably be treated as an invalid expiry. "No input" isn't handled by the TypeDef, it just results in the API module receiving null.

The watchlist expiries would handle receiving that null as "no change". Something that wanted to interpret it as "indefinite" would probably just set PARAM_DEFAULT => 'indefinite' so it would never receive the null in the first place. Something that wanted to force the user to always explicitly specify the expiry would set PARAM_REQUIRED => true.

Change 585297 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/core@master] [WIP] Add expiry type to ParamValidator

https://gerrit.wikimedia.org/r/585297

Change 585297 merged by jenkins-bot:
[mediawiki/core@master] Add expiry type to ParamValidator

https://gerrit.wikimedia.org/r/585297

I briefly tested the validation of the expiry parameter for API:Watch and Special:ApiSandbox.

For regression, because we modified the code for wfIsInfinity(), I tested the expiry parameter of Special:Block.