On Thursday, 20 March 2025 04:59:52 Pacific Daylight Time Sebastian Wittmeier
wrote:
> One header file would define an interface (e.g. some free functions),
> another header file would declare, which ones are actually implemented. The
> calling code sees overload resolution and so on, as if all functions exist,
> but there is a compilation error for those only declared as
> "unimplemented".
>
> To modify the first header file (e.g. with preprocessor conditionals) would
> be cumbersome. However, each (partly) implementation could just copy the
> first header file and =delete the functions it does not implement.

No, it wouldn't be cumbersome. I am arguing that in the non-fragile case,
there's only one party writing both declarations. As such, this one person can
edit the first declaration.

Or, put conversely, I am arguing that two parties trying to declare the same
thing is fragile, fraught with error. The example given before (__modfd128 or
something) is considering overriding runtime functions, which is a big no-no
if ever there was one. Declaring anything inside of the std namespace is UB,
unless explicitly allowed by the standard.

What happens, for example, if the declaration with [[unimplemented]] decides
to change something in the declaration but keep source compatibility, such as
adding a defaulted extra parameter, changing the noexcept or requires
constraints, changing any of the template expressions if it is a template
function? That means we'll have made things worse by probably introducing
ambiguity.

Hans mentioned in the last email about this being a temporary fix for some
problem. That sounds like the kind of stuff Frederick kept on suggesting for
debugging and working around problems. If that's the only objective here, then
the proposal should say so, but then must analyse other temporary kludges and
argue why it should be in the standard in the first place.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering