Intergal specs: 💃👓💃. (No change requested, just thought this was a funny typo.)

I do not get why we are pulling those algorithms out. We do not really want the bounds checks and we already have the unchecked iterators ready.

Why not simply call _RANGES _Find_unchecked and _RANGES _Copy_unchecked ?

For calling directly with range arguments when we don't have iterators handy, it's much simpler to call the range algorithm. (Recall that Range algorithms with range arguments don't perform bounds checks - they trust that begin() and end() return a valid range.)

What is it with these newlines?

In a switch with cases that fall through, I like to use newlines after only the cases that do not fall through as a visual reinforcement of the control flow structure.

I belive this is broken

1. We should use _RANGES _Unchecked_find
2. If we have wide characters this is only one element, so we should not search
3. If we have plain characters you just changed _Fill to only contain _CharType( ) so you will always find end(_Specs._Fill)

we might want to just store the length in character types of the fill character array

1. I'm too lazy to call begin and end on a range when the range algorithm can do it for me.
2. Wide characters are UTF-16 on our implementation, so two may be needed to represent a fill character (the test case that uses 🏈, for example).
3. meow woof[4] = {quack}; is equivalent to meow woof[4] = {quack, {}, {}, {}};, not to meow woof[4] = {quack, quack, quack, quack};.

we might want to just store the length in character types of the fill character array

I'm largely indifferent; it's just another char in _Basic_format_specs. I'll happily make the change if you think it's warranted; please say so more definitively than "we might."

Ditto _RANGES _Unchecked_copy

Ditto "I see no benefit commensurate with the additional code". Do you?

we might want to just store the length in character types of the fill character array

Are non-UTF-8 4-byte encodings (e.g. GB18030/code page 54936) possible here?

This function (which is effectively a partially-inlined call to _Mbrtowc, which implements the equivalent for std::codecvt) and _Mbrtowc certainly don't think so. I'd like to do better, but I'm not prepared to overhaul how our locale machinery deals with character encodings in this PR.

Background: _Mbrtowc is a wrapper around a call to MultiByteToWideChar which relies on the anachronistic assumption that any encoded character can be converted to a single UCS-2 code unit. This is clearly wrong and has been for many years, but it's the mechanism we have right now for determining the extent of multibyte characters. I think we can do better, especially now that ICU is available so we may not need to write and maintain enormous quantities of per-supported-encoding code.

This doesn't properly nor consistently handle all invalid UTF-8. We should either treat the partial/invalid code units as a "�" (details omitted) upon all invalid UTF-8 and continue parsing (this is the preferred default error handling method for decoding regular UTF-8 text), or throw format_error upon all invalid UTF-8.

Test cases:

I've made no attempt to validate the encoding of the format string - we don't examine continuation bytes at all. I've only done the minimal amount of work needed to avoid running off the end of the format string. This seems reasonable for code that parses format strings, which are generally trusted.

Weirdness: we don't do width estimation for fill characters, the spec simply assumes they have width 1. Consequently, format("{:3.2}", "日本地図") yields "日 ", whereas format("{:本<3.2}", "日本地図") yields "日本". This seems like a standard defect.

possible future performance optimization would be branch prediction annotations.

I thought about this, but decided to avoid them. The vague "arbitrarily more/less likely" wording in the Standard means you don't know if a compiler will reorder branches a bit, or move unlikely branches off into the wilderness with cold exception-throwing code. Something like the latter can be catastrophic to performance when you really are just making a guess about the distribution of inputs. I'm happy with ordering the branches by what we feel is decreasing frequency and leaving anything further to folks running PGO with (hopefully) representative inputs.