Description
In #116161 the extended_varargs_abi_support
feature was stabilized, effectively without a stabilization report. As far as I can find, it was also without an FCP for either relevant team, neither T-compiler nor T-lang. It seems like it wasn't really discussed extensively, or at least I can't find the meat of the discussion? I am guessing people felt it was conceptually good to go ahead... but no FCP was initiated, and there was no RFC for it either.
There is a bit of confusion to me on this point because extern "system"
, on the (ahem) systems where it is meaningful (i.e. distinct from extern "C"
in some way), is translated to extern "stdcall"
which is incompatible in varargs. In the PR where extern "system"
was added to extended_varargs_abi_support
, it was proposed to make extern "system"
transparently translate to extern "C
" when varargs are involved because sometimes the MSVC toolchain will make that implicit translation: #119587 (comment)
However, in #87678 we added a future compatibility warning specifically for the fact that we realized, a bit late, that we didn't actually want to support this sort of implicit ABI translation, and preferred to have these names be, er... meaningful? We had decided we wanted to limit the use of these ABIs to cases where they had an explicit and clearly indicated meaning, so that we can e.g. give them the meanings they may need to have if they are in fact given such a meaning in the future... or at least not have pointless confusion.
Thus there are a few problems, mostly about process:
- A decision that needed an FCP (from some team) glided through without one?
- The initial feature kept feature-creeping through gradual additions without much discussion and the "has this been suitably reflected on?" checking process (a stability report) did not kick in, resulting in a decision that seems inconsistent being made without apparent discussion of that inconsistency.