Hi Thiago,   First, it is not my proposal. I am just trying to help understanding the use case and suggestion.     > Why do you have both declarations in the first place? Why can't you just edit the first one and drop the =delete("Unimplemented") portion?       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.   The include order probably is no problem. Just say that [[unimplemented]] may be declared before or after the declaration without that attribute. Although the second header file could include the first one to make sure of  the include order. An overall interface should come before the declaration, which functions of the interface are actually implemented.   I will not defend the use case, except the original poster (Samuel) will confirm that I got the workings and the use case, he intended. I do not see a strong need, but some possible usefulness. I would rename it from [[unimplemented]] to [[interface]], as the first declaration does not say or know, whether it is implemented, only the second declaration gives the answer.   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 19.03.2025 23:51 Betreff:Re: [std-proposals] unimplemented attribute An:std-proposals_at_[hidden]; CC:Thiago Macieira <thiago_at_[hidden]>; On Wednesday, 19 March 2025 11:56:23 Pacific Daylight Time Sebastian Wittmeier via Std-Proposals wrote: > That is probably the best explanation. >   > So we would potentially have 3 declarations/definitions: > >  - An [unimplemented] declaration > >  - An actual declaration Why do you have both declarations in the first place? Why can't you just edit the first one and drop the =delete("Unimplemented") portion? I see no reason why two separate projects would be trying to complement themselves this way. It would be fragile: what happens if the include order changes somehow and the second definition isn't available? Why is the third codebase that needs this function even including the first? And what happens if the first one suddenly starts providing the functionality, will the compilation break because of double definition of the function? The more likely condition is that the second project implementing the functionality provides it with a different function name, which the third code uses, and we ignore the =delete'd declaration as irrelevant. >  - A definition (possibly in another TU) >   > In the status quo, if the actual declaration and the definition is combined, > the error would appear in the link stage. But the error should be earlier. > > In the status quo, if the unimplemented declaration would delete instead, > this decision could not be overridden, e.g. in another included header. I'm questioning this motivation: how can you be sure of reliably overriding a declaration in a situation where simply modifying the declaration isn't possible? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org  Principal Engineer - Intel DCAI Platform & System Engineering -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals