expected: force polyfill on all platforms to fix Linux-only -fno-exceptions build

Linux CI (clang + libstdc++-13) fails while macOS (libc++) and Windows
(MSVC STL) pass because only libstdc++ gates __cpp_lib_expected under
C++20, pulling in the real <expected> and its std::unexpected, which
collides with libstdc++'s legacy void std::unexpected().

Use the exception-free kyty:: polyfill unconditionally on every platform.
All call sites already use kyty::expected / kyty::unexpected, so no caller
changes are needed. include/ and src/ copies remain byte-identical.

Author: Coder787-source

include/kyty_expected.hpp

@@ -6,33 +6,19 @@
 // Deliberately NOT defined in namespace std:
 //   * defining names in namespace std is undefined behavior,
 //   * libstdc++ >= 13 declares a legacy function `void std::unexpected()`
-//     which would collide with a class template of the same name.
-// `kyty::expected` / `kyty::unexpected` are provided via using-declarations.
+//     which collides with the real std::unexpected<T> from <expected>-which,
+//     on clang+libstdc++, is also selected by __cpp_lib_expected under C++20.
+//
+// Therefore the polyfill below is used UNCONDITIONALLY on every platform.
+// Linux (clang + libstdc++), macOS (clang + libc++) and Windows (clang-cl +
+// MSVC STL) must all take the exact same branch, otherwise a hard error
+// appears only on Linux. All call sites use kyty::expected / kyty::unexpected.
 //
 // Exception-free: the project builds with -fno-exceptions on Linux/macOS, so
 // value()/error() on the wrong state assert() in debug builds instead of
 // throwing. (In release builds an unguarded wrong-state access trips the
 // variant's own error path - a loud failure, never silent UB.)
 
-#include <version>
-
-#if defined(__cpp_lib_expected) && __cpp_lib_expected >= 202202L
-
-#include <expected>
-
-namespace kyty {
-
-using std::bad_expected_access;
-using std::expected;
-using std::unexpected;
-
-template <class E>
-unexpected(E) -> unexpected<E>;
-
-} // namespace kyty
-
-#else
-
 #include <cassert>
 #include <type_traits>
 #include <utility>
@@ -246,5 +232,3 @@ class expected<void, E> {
 };
 
 } // namespace kyty
-
-#endif

src/kyty_expected.hpp

@@ -6,33 +6,19 @@
 // Deliberately NOT defined in namespace std:
 //   * defining names in namespace std is undefined behavior,
 //   * libstdc++ >= 13 declares a legacy function `void std::unexpected()`
-//     which would collide with a class template of the same name.
-// `kyty::expected` / `kyty::unexpected` are provided via using-declarations.
+//     which collides with the real std::unexpected<T> from <expected>-which,
+//     on clang+libstdc++, is also selected by __cpp_lib_expected under C++20.
+//
+// Therefore the polyfill below is used UNCONDITIONALLY on every platform.
+// Linux (clang + libstdc++), macOS (clang + libc++) and Windows (clang-cl +
+// MSVC STL) must all take the exact same branch, otherwise a hard error
+// appears only on Linux. All call sites use kyty::expected / kyty::unexpected.
 //
 // Exception-free: the project builds with -fno-exceptions on Linux/macOS, so
 // value()/error() on the wrong state assert() in debug builds instead of
 // throwing. (In release builds an unguarded wrong-state access trips the
 // variant's own error path - a loud failure, never silent UB.)
 
-#include <version>
-
-#if defined(__cpp_lib_expected) && __cpp_lib_expected >= 202202L
-
-#include <expected>
-
-namespace kyty {
-
-using std::bad_expected_access;
-using std::expected;
-using std::unexpected;
-
-template <class E>
-unexpected(E) -> unexpected<E>;
-
-} // namespace kyty
-
-#else
-
 #include <cassert>
 #include <type_traits>
 #include <utility>
@@ -246,5 +232,3 @@ class expected<void, E> {
 };
 
 } // namespace kyty
-
-#endif