That is probably the best explanation.   So we would potentially have 3 declarations/definitions:  - An [unimplemented] declaration  - An actual declaration  - 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. In the status quo, if the unimplemented declaration would just be left out, the actual declaration would not have to follow the unimplemented declaration, or if it does not exist, the call site would not be checked well,   So it is kind of an unimplemented "interface", until it is declared as implemented.   -----Ursprüngliche Nachricht----- Von:Andre Kostur via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 19.03.2025 16:48 Betreff:Re: [std-proposals] unimplemented attribute An:std-proposals_at_[hidden]; CC:Andre Kostur <andre_at_[hidden]>; Not that I agree with the proposal, but the scenario I'm hearing: 1) A cpp file includes a header with an [[unimplemented]] function (say the modf example above) 2) That cpp file then includes a header with the same function, but this time without the [[unimplemented]] attribute 3) The cpp file then calls that function. If one was to use =delete instead, #2 would be a compiler error as that would be redeclaring the same function.  And if #2 doesn't exist, then the compilation could emit a diagnostic (before it got to the link stage).  Though I'm not yet sold that simply not declaring the function at all isn't the better option anyway.