feat(core): multi-format ParseExact across all five exact-parsing types (#1944)

The last open post-audit implementation ticket.

One ordered first-success loop shared by DateTime, DateTimeOffset, DateOnly,
TimeOnly and TimeSpan -- five copies of one taxonomy is how five doors come to
disagree, and .NET writes it twice with the two agreeing.

Ordering is pinned with an input two formats both accept: 01/02/2024 is 2
January under MM/dd and 1 February under dd/MM, so the two orders give different
DATES rather than a different code path. An empty ELEMENT aborts the whole loop
rather than being skipped, and the pin puts it before a format that would have
matched, so the plausible-wrong rule succeeds where the right one fails.

Two failure kinds, because .NET gives them two messages -- found by measurement:
with the empty-collection guard removed the loop body never runs and the
fall-through gives the same answer, so it would have been a proven equivalence.
Carrying both messages makes it load-bearing and gives the right diagnosis.

The overload hazard the acceptance criteria anticipated was real: {"a", "b"} and
{"one"} were ambiguous, because two const char* in braces match
basic_string(InputIt, InputIt) over two UNRELATED pointers -- and had that
candidate won, the result would be undefined behaviour rather than a wrong
answer, which is what decided a fix over documenting a papercut.
initializer_list overloads resolve it, and a case asserts the unbraced
single-format overload is still reachable.

Four mutations, three caught; M3 is a proven equivalence recorded at the site,
and .NET's is an equivalence too.

The span-like shapes are recorded rather than taken: a second text
representation beside const std::string& repeats this very hazard, where the
wrong branch is silent rather than ambiguous.

Gate 17,732/38 green. Zero downstream sites.

Author: robertvokac

CLAUDE.md

@@ -139,6 +139,32 @@
 > and each is itemised in §2 below. **§4b says where to look next, and the method that found all
 > three of today's tickets.**
 
+## 2026-08-20 — #1944: multi-format `ParseExact` — **the last open post-audit ticket**
+
+**Gate: 17,732 / 38, 0 failed, 0 skipped** (+7, `Core_Base` 6,141 → 6,148).
+
+All five exact-parsing types gain multi-format `ParseExact`, sharing **one** ordered first-success
+loop. **Ordering is pinned with an input two formats both accept**: `01/02/2024` is 2 January under
+`MM/dd` and 1 February under `dd/MM`, so the two orders give **different dates**.
+
+**An empty element aborts the whole loop rather than being skipped** — the pin puts it *before* a
+format that would have matched, so the plausible-wrong rule succeeds where the right one fails.
+
+**Two failure kinds, because .NET gives them two messages**, and that was found by measurement: with
+the empty-collection guard removed the loop never runs and the fall-through gives the same answer,
+so it **would have been a proven equivalence**.
+
+**The overload hazard the acceptance criteria anticipated was real.** `ParseExact(s, {"a", "b"})`
+and `{"one"}` were **ambiguous**, because two `const char*` in braces match
+`basic_string(InputIt, InputIt)` over two **unrelated** pointers — **and had that candidate won, the
+result would be undefined behaviour**, which is what decided a fix over documenting a papercut.
+`std::initializer_list` overloads resolve it.
+
+**The span-like shapes are recorded rather than taken**: a second text representation beside
+`const std::string&` repeats this very hazard, in a place where the wrong branch is *silent*.
+
+`docs/Migration-MultiFormatParseExact.md`. Downstream zero sites.
+
 ## 2026-08-20 — #2416: `DateTime::ToString` had no standard-format table at all
 
 **Gate: 17,725 / 38, 0 failed, 0 skipped** (+5, `Core_Base` 6,136 → 6,141; **no other executable

NEXT.md

@@ -0,0 +1,91 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) Robert Vokac and contributors -->
+
+# Multi-format `ParseExact` across all five exact-parsing types — #1944
+
+**Purely additive**, under SA-5. No existing signature, layout, vtable, `noexcept` specification or
+accepted input changed. This is the **last open post-audit implementation ticket**.
+
+## One loop for five types
+
+`DateTime`, `DateTimeOffset`, `DateOnly`, `TimeOnly` and `TimeSpan` all gain
+`ParseExact(input, formats, …)` / `TryParseExact(…)`. The ordered first-success loop is
+`detail::MatchFirstOfManyFormats`, written **once** — five copies of one taxonomy is how five doors
+come to disagree about what an empty element means. .NET writes it twice
+(`TryParseExactMultiple`, `TryParseExactMultipleTimeSpan`) and the two agree, so sharing is faithful
+rather than a shortcut.
+
+## The rules, and the one a plausible implementation gets wrong
+
+* **Ordered, first success wins.** Pinned with an input two formats both accept:
+  `01/02/2024` is 2 January under `MM/dd` and 1 February under `dd/MM`, so the two orders give
+  **different dates** rather than merely a different code path.
+* **An empty element ABORTS the whole loop rather than being skipped.** .NET returns
+  `SetBadFormatSpecifierFailure` immediately. *"Skip it and carry on"* is the plausible
+  implementation and it is wrong; the pin puts the empty element **before** a format that would
+  have matched, so the wrong rule succeeds where the right one fails.
+* **An empty collection is a FORMAT failure, not an argument one** — .NET's
+  `Format_NoFormatSpecifier`, easy to get wrong in the direction of `ArgumentException`.
+* **.NET's null-array arm has no C++ counterpart** and is deliberately not reproduced: the
+  parameter is a `const std::vector<std::string>&`, which cannot be null.
+* **The style is validated once, before the loop**, so an illegal style raises whatever the formats
+  are — including an empty collection, where no single-format call would ever run. Validating
+  inside the loop would make the exception depend on the format list.
+
+## Two failure kinds, because .NET gives them two messages
+
+Measured while writing the tests: with the empty-collection guard simply **removed**, the loop body
+never runs and the fall-through gives the same answer — so the guard would be a **proven
+equivalence** and the mutation uncaught. But **.NET's two failures carry different messages**:
+*"No format specifiers were provided."* against *"String was not recognized as a valid …"*.
+
+Carrying both makes the guard load-bearing **and** gives the right diagnosis: telling a caller who
+supplied no formats that their *input* was unrecognised is wrong. An **empty element** gets the
+format-specifier message too, being the same kind — the caller's formats are wrong, not their input.
+
+## The overload-resolution hazard the ticket anticipated
+
+#1944's acceptance criteria asked for *"compile ambiguity fixtures"*, and there was a real one.
+Measured with a five-way probe:
+
+| spelling | before |
+|---|---|
+| `ParseExact(s, {"a", "b"})` | **ambiguous** |
+| `ParseExact(s, {"one"})` | **ambiguous** |
+| `ParseExact(s, {"a", "b", "c"})` | ok |
+| `ParseExact(s, std::vector<std::string>{…})` | ok |
+| `ParseExact(s, {std::string("a"), std::string("b")})` | ok |
+
+Two `const char*` in braces match `std::basic_string(InputIt first, InputIt last)` over two
+**unrelated** pointers, so the single-format overload was a candidate — **and if it had ever won,
+the result would be undefined behaviour rather than a wrong answer.** That is what decided the fix
+rather than documenting the papercut.
+
+`std::initializer_list<std::string>` overloads resolve it: a braced list binds to an
+`initializer_list` parameter by a **list-initialization sequence**, which outranks any user-defined
+conversion, so the dangerous candidate can no longer win. All five spellings now compile, and a
+case asserts the **unbraced** single-format overload is still reachable — the half a fix aimed only
+at the braced spelling could have broken.
+
+## Evidence
+
+Four mutations, **three caught**. **M3 is a proven equivalence, recorded at the site rather than
+counted**: with the empty-input guard removed the loop still runs, every format fails to match an
+empty input, and the fall-through returns the same outcome with the same message. **.NET's is an
+equivalence too** — its `s.Length == 0` arm and its all-formats-failed arm are both
+`SetBadDateTimeFailure`, one kind and one text — so the line is a statement of intent, kept because
+it is .NET's and because it says *why* an empty input cannot succeed without relying on every
+format's scanner to refuse it. One mutation was **invalid as first written** and reformulated
+rather than counted (`-Werror=unused-parameter`).
+
+Gate: **17,732 / 38, 0 failed, 0 skipped** (+7; `SharpRuntimeTests_Core_Base` 6,141 → 6,148).
+Module graph **41 / 95**. Downstream: **zero sites** — the members did not exist.
+
+## What #1944 asked for and did not get
+
+The **span-like** shapes. `System::ReadOnlySpan<char>` exists in this port, and `std::string_view`
+is the idiomatic C++ counterpart, but neither is added: **every exact-parsing door here takes
+`const std::string&`**, and adding a second text representation beside it repeats exactly the
+overload hazard this ticket just closed, in a place where the wrong branch is silent rather than
+ambiguous. It is recorded here rather than taken, because it is a public-shape decision and the
+collection half — which is what every multi-format caller actually needs — is complete without it.

docs/Migration-MultiFormatParseExact.md

@@ -2,6 +2,8 @@
 // Copyright (c) Robert Vokac and contributors
 // Portions based on .NET runtime API (MIT License, Copyright .NET Foundation and Contributors)
 #pragma once
+#include <initializer_list>
+#include <vector>
 #include "System/Globalization/DateTimeStyles.hpp"
 #include "System/IFormatProvider.hpp"
 #include <string>
@@ -243,6 +245,62 @@ namespace System {
                                   const System::IFormatProvider* provider,
                                   System::Globalization::DateTimeStyles style, DateOnly& result);
 
+        /**
+         * @brief Parses @p input against the FIRST of @p formats that matches (#1944).
+         *
+         * C++ counterpart of .NET `DateOnly.ParseExact(string, string[], IFormatProvider, ...)`.
+         *
+         * @note **AN EMPTY ELEMENT ABORTS THE WHOLE LOOP RATHER THAN BEING SKIPPED** -- .NET
+         *       returns its bad-format-specifier failure immediately rather than trying the next
+         *       entry, and "skip it and carry on" is the plausible implementation that is wrong.
+         *
+         * @note **AN EMPTY COLLECTION IS A FORMAT FAILURE, NOT AN ARGUMENT ONE**, and .NET's
+         *       **null array** arm has no C++ counterpart here: the parameter is a
+         *       `const std::vector<std::string>&`, which cannot be null.
+         */
+        [[nodiscard]] static DateOnly ParseExact(
+            const std::string& input, const std::vector<std::string>& formats,
+            const System::IFormatProvider* provider = nullptr,
+            System::Globalization::DateTimeStyles style = System::Globalization::DateTimeStyles::None);
+
+        /** @brief Non-throwing counterpart of the multi-format ParseExact. */
+        static bool TryParseExact(const std::string& input,
+                                  const std::vector<std::string>& formats,
+                                  const System::IFormatProvider* provider,
+                                  System::Globalization::DateTimeStyles style, DateOnly& result);
+
+        /**
+         * @brief `std::initializer_list` overload of the multi-format ParseExact (#1944).
+         *
+         * **THIS EXISTS TO KEEP A BRACED LIST OUT OF `std::string`'s ITERATOR-PAIR CONSTRUCTOR,
+         * and the wrong branch is undefined behaviour rather than merely a wrong overload.**
+         * Measured: without it, `ParseExact(s, {"a", "b"})` is **ambiguous** between the
+         * single-format `(string, string)` -- where two `const char*` in braces match
+         * `basic_string(InputIt first, InputIt last)` over two **unrelated** pointers -- and the
+         * multi-format one. `{"one"}` is ambiguous too; three or more elements are not, and an
+         * explicit `std::vector<std::string>{...}` never was.
+         *
+         * A braced list binds to an `initializer_list` parameter by a **list-initialization
+         * sequence**, which outranks any user-defined conversion, so this overload takes it
+         * unambiguously and the dangerous candidate can no longer win.
+         */
+        [[nodiscard]] static DateOnly ParseExact(
+            const std::string& input, std::initializer_list<std::string> formats,
+            const System::IFormatProvider* provider = nullptr,
+            System::Globalization::DateTimeStyles style = System::Globalization::DateTimeStyles::None) {
+            return ParseExact(input, std::vector<std::string>(formats), provider,
+                              style);
+        }
+
+        /** @brief `std::initializer_list` overload of the multi-format TryParseExact. */
+        static bool TryParseExact(const std::string& input,
+                                  std::initializer_list<std::string> formats,
+                                  const System::IFormatProvider* provider,
+                                  System::Globalization::DateTimeStyles style, DateOnly& result) {
+            return TryParseExact(input, std::vector<std::string>(formats), provider,
+                                 style, result);
+        }
+
         /** @brief Returns true if this date equals the specified date. */
         bool operator==(const DateOnly& o) const { return year_==o.year_ && month_==o.month_ && day_==o.day_; }
         /** @brief Returns true if this date does not equal the specified date. */

modules/core/include/System/DateOnly.hpp

@@ -2,6 +2,8 @@
 // Copyright (c) Robert Vokac and contributors
 // Portions based on .NET runtime API (MIT License, Copyright .NET Foundation and Contributors)
 #pragma once
+#include <initializer_list>
+#include <vector>
 
 #include <string>
 #include "System/DateTimeKind.hpp"
@@ -586,6 +588,72 @@ namespace System {
                                   DateTime& result,
                                   const System::ILocalTimeZone* zone = nullptr);
 
+        /**
+         * @brief Parses @p input against the FIRST of @p formats that matches (#1944).
+         *
+         * C++ counterpart of .NET `DateTime.ParseExact(string, string[], IFormatProvider,
+         * DateTimeStyles)`.
+         *
+         * @note **AN EMPTY ELEMENT ABORTS THE WHOLE LOOP RATHER THAN BEING SKIPPED**, which is the
+         *       rule a plausible implementation gets wrong: .NET returns its bad-format-specifier
+         *       failure immediately rather than trying the next entry.
+         *
+         * @note **AN EMPTY COLLECTION IS A FORMAT FAILURE, NOT AN ARGUMENT ONE** -- .NET's
+         *       `Format_NoFormatSpecifier` -- so a caller passing no formats gets
+         *       `FormatException`, which is easy to get wrong in the direction of
+         *       `ArgumentException`.
+         *
+         * @note .NET's **null formats array** raises `ArgumentNullException`; that arm has **no
+         *       C++ counterpart here** and is deliberately not reproduced, the parameter being a
+         *       `const std::vector<std::string>&` that cannot be null.
+         */
+        [[nodiscard]] static DateTime ParseExact(
+            const std::string& input, const std::vector<std::string>& formats,
+            const System::IFormatProvider* provider = nullptr,
+            System::Globalization::DateTimeStyles styles = System::Globalization::DateTimeStyles::None,
+            const System::ILocalTimeZone* zone = nullptr);
+
+        /** @brief Non-throwing counterpart of the multi-format ParseExact. */
+        static bool TryParseExact(const std::string& input,
+                                  const std::vector<std::string>& formats,
+                                  const System::IFormatProvider* provider,
+                                  System::Globalization::DateTimeStyles styles, DateTime& result,
+                                  const System::ILocalTimeZone* zone = nullptr);
+
+        /**
+         * @brief `std::initializer_list` overload of the multi-format ParseExact (#1944).
+         *
+         * **THIS EXISTS TO KEEP A BRACED LIST OUT OF `std::string`'s ITERATOR-PAIR CONSTRUCTOR,
+         * and the wrong branch is undefined behaviour rather than merely a wrong overload.**
+         * Measured: without it, `ParseExact(s, {"a", "b"})` is **ambiguous** between the
+         * single-format `(string, string)` -- where two `const char*` in braces match
+         * `basic_string(InputIt first, InputIt last)` over two **unrelated** pointers -- and the
+         * multi-format one. `{"one"}` is ambiguous too; three or more elements are not, and an
+         * explicit `std::vector<std::string>{...}` never was.
+         *
+         * A braced list binds to an `initializer_list` parameter by a **list-initialization
+         * sequence**, which outranks any user-defined conversion, so this overload takes it
+         * unambiguously and the dangerous candidate can no longer win.
+         */
+        [[nodiscard]] static DateTime ParseExact(
+            const std::string& input, std::initializer_list<std::string> formats,
+            const System::IFormatProvider* provider = nullptr,
+            System::Globalization::DateTimeStyles styles = System::Globalization::DateTimeStyles::None,
+            const System::ILocalTimeZone* zone = nullptr) {
+            return ParseExact(input, std::vector<std::string>(formats), provider,
+                              styles, zone);
+        }
+
+        /** @brief `std::initializer_list` overload of the multi-format TryParseExact. */
+        static bool TryParseExact(const std::string& input,
+                                  std::initializer_list<std::string> formats,
+                                  const System::IFormatProvider* provider,
+                                  System::Globalization::DateTimeStyles styles, DateTime& result,
+                                  const System::ILocalTimeZone* zone = nullptr) {
+            return TryParseExact(input, std::vector<std::string>(formats), provider,
+                                 styles, result, zone);
+        }
+
         using Object::Equals;
 
         /**