/**
* Memoised `Intl` formatters, keyed by locale + options.
*
* WHY THIS EXISTS, AS A MEASUREMENT (gh#557). A consumer ported a legacy CakePHP grid that keeps
* every row in the DOM — 8,262 rows, no virtualisation available — and measured 27-30s against
* 2.3s for the same markup built from native ` ` / ``. They had already ruled out
* the obvious suspect: deleting `Popover` / `PopoverContent` from `DatePicker` entirely changed
* nothing.
*
* Rendered here through `react-dom/server`, 2,000 rows at a time, one CLOSED `DatePicker` costs
* **412.6us** against **4.2us** for ` ` — 98x. Counting constructor calls during
* that render, each closed instance built:
*
* 12 x new Intl.DateTimeFormat
* 1 x new Intl.NumberFormat
*
* Constructing an `Intl` formatter is one of the most expensive things a JS engine does: it
* resolves locale data and compiles a pattern. Routing those same constructions through this
* cache, changing nothing else, took the instance from **412.6us to 178us — a 57% cut**. For the
* reporter's grid that is roughly 99,000 formatter constructions that no longer happen.
*
* WHY A SHARED MODULE AND NOT A `useMemo` AT EACH CALL SITE. `useMemo` memoises per INSTANCE, and
* the instance is exactly what there are 8,262 of. Two rows formatting dates in the same locale
* want the same formatter object, and nothing below module scope can give them one.
*
* SAFETY. `Intl` formatters are immutable and stateless — `format()` mutates nothing — so a single
* instance is safely shared across every caller and every React tree, concurrent SSR included.
*/
export declare function dateTimeFormat(locale: string, options?: Intl.DateTimeFormatOptions): Intl.DateTimeFormat;
export declare function numberFormat(locale: string, options?: Intl.NumberFormatOptions): Intl.NumberFormat;
export declare function pluralRules(locale: string, options?: Intl.PluralRulesOptions): Intl.PluralRules;
export declare function listFormat(locale: string, options?: Intl.ListFormatOptions): Intl.ListFormat;