Oh but contrare, such an API SHOULD be standardised. How do you think
iconv(), WideCharToMuliByte() and MultiBytToWideCharf exist? By ignoring
assumptions in the data types. They're explicitly stating (with the void*
pointer parts) they they give no s**ts about assumed encodings associated
with whatever type is being used for the strings passed in. It is in such
cases that the "API that ignores assumptions" is standardised, at least
within there own ecosystem. Frankly I would like a standard variant of that
combines the best parts of both APIs. something like:

/// @brief get codepage
long getstrcp( char const *name );
/** @brief try to convert from source codepage (scp) to destination
codepage (dcp)
@return If dst is NULL or cap < 1 then the size of the allocation needed
for dst to be completely converted (including final \0),
otherwise returns the number of characters converted, not including the \0
character appended at the end
**/
long strconv( long dcp, void *dst, long cap, long scp, void const *src,
long end );

along with some optional inlines like these to make it easier to use when
said types are used:

inline utfconv8to16( char16_t *dst, long max, char8_t const *src, long len )
   { return strconv( 1200, dst, max * sizeof(char16_t), 65001, src, len *
sizeof(char8_t) ); }
inline utfconv8to32( .char32_t *dst, ... )
   { return strconv( 12000, dst, ... ); }
inline utfconv16to8( char8_t *dst ... )
   ...

Would make things much more convenient to work with and the API would be
conveying the assumptions it's applying directly to the developer

On Sun, 31 Aug 2025 at 17:13, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Aug 31, 2025 at 10:54 AM Sebastian Wittmeier via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > A function could just forward a string to another function or to a
> platform API, without assuming any encoding.
>
> Yes, it can. That function could also be implemented to assume that
> the `char16_t` string is instead encoded in GB18030 rather than
> UTF-16. Regardless of *how* the assumption is violated, it is
> understood that a function can violate those assumptions.
>
> But such an API should not be *standardized*. That is, the C++
> standard *ought to* presume the encoding of strings using those
> character types, and it should not introduce any functions that don't
> abide by those rules.
>
> The standard can't enforce compliance with reasonable coding
> practices. But at least it can maintain those for itself.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>