This is my understanding of the proposal.

Take for example the following:

int foo(float);
int foo(double); //unimplemented

template<typename T> requires requires ( T val ) { foo(val); }
struct foo_props_t{};


Now look at the following usage.

foo_props_t<double> var;
foo(1.0);

If `int foo(double);`is omitted and not forward declared, both the instantiation of this template and the call of foo would succeed, because the double is simply implicitly converted to a float.
But what if we don’t double to implicitly promote to a float?

If `int foo(double) = delete;` then both the instantiation of the template and the call to a function would fail, because the double version is explicitly deleted.

The new proposal `[[unimplemented]] int foo(double);` would cause the instantiation of the template to succeed, there’s nothing stopping the instantiation of the structure just because foo is not implemented, but calling foo would fail.

I think the proposal is trying to do is:
1. Allow the definition of the function and allow multiple overloads, and avoid potential variable promotion. (not suitable if not defined)
2. Allow the evaluation as if the function existed in an evaluated context. (not suitable if marked deleted)
3. Still fail if a user tries to use the function explicitly. (not suitable if unmarked)

Maybe you don’t want to implement it right now, so it can’t provide you with the function, but there’s nothing stopping reasoning about at compile time as if the function existed.

So, to answer your questions:


> For the second part, how would a user implement it?



They don’t. It’s not implemented, that is what it is intended to mark.



> - Is the function defined in the same translation unit?



It’s never defined.



> - Or only declared? This time without [[unimplemented]]?



Yes.



> - Or both defined and declared?



Just declared.



> - Or nothing would change in the translation unit, but the user would turn off the unimplemented warnings? And the linker would do the rest?

The compiler would fail to compile if used explicitly and never reach the linker. Stopping the user from using an unimplemented function, but still be able to properly implement other overloads for other types without the fear that the forbidden types would be implicitly converted to something else, and be able to still be able to work with compile time introspection.

Did I get this right?







From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Thursday, March 20, 2025 4:53 PM
To: std-proposals_at_[hidden]
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] unimplemented attribute


So - as others have written - for the first part you have to argue, why it is much different from declaring either as =delete or not at all.

For the second part, how would a user implement it?

 - Is the function defined in the same translation unit?

 - Or only declared? This time without [[unimplemented]]?

 - Or both defined and declared?

 - Or nothing would change in the translation unit, but the user would turn off the unimplemented warnings? And the linker would do the rest?

In the fourth option: If this is done a lot and the warnings are turned on again, one would not know, which functions are and which functions are not implemented.



Generally, you also should describe, why it is such a bad thing, if the linker finds out that symbols are missing. If it is just the error message, which often does not refer well to the line of code calling the function, perhaps that can be changed.






-----Ursprüngliche Nachricht-----
Von: Hans Åberg via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
It means that it is not implemented but is called for by a specification such as the C++ standard.

If you call such a function, you get a compiler diagnostic saying that it is not implemented. That is the first part.

The second part is the ability to implement it on your own. This part is tricky, and it is unclear if it can be admitted.