On 20/04/2026 15:46, Ville Voutilainen via Std-Proposals wrote:
> On Mon, 20 Apr 2026 at 16:08, Muneem via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> A simpler way to fix this issue would be to simply allow "explicit" arguments just like how we make constructors explicit.
>
> C++ already has something so close to explicit arguments that a
> separate language facility is without merit:
> https://godbolt.org/z/b8xv6EdPn
>
> Pasted for convenience:
>
> #include <concepts>
>
> void f(std::same_as<int> auto x) {}
>
> int main()
> {
> f(42); // Ok
> //f(42.42); // Ill-formed
> f(static_cast<int>(42.42)); // Ok
> }

That is fine as far as it goes (and thank you for the suggestion), but
it is inconvenient to write, especially if the implementation is in a
separate implementation file (not an included header). Then you need :

// header.h
#include <concepts>

void f(std::same_as<int> auto x);

// implementation.cpp
#include "header.h"

void f(std::same_as<int> auto x)
{ ... }
template void f(int); // Force linkable instantiation


A hypothetical "explicit" qualifier (if I've got the correct syntactical
term here) for parameters would only be needed in a declaration. And
now the function would not be a template. You'd have:


// header.h
#include <concepts>

void f(explicit int x);

// implementation.cpp
#include "header.h"

void f(int x)
{ ... }

// or, according to preference

void f(explicit int x)
{ ... }



But I think your original idea could be made a little neater (that's a
subjective opinion, and I am very open to more improvements or
alternative opinions) :

// explicit.h reusable header
#include <concepts>

template <typename T>
class Explicit {
private :
     T x_;
public :
     constexpr Explicit(std::same_as<T> auto x) : x_(x) {}
     constexpr operator T() const { return x_; }
};


// header.h
#include "explicit.h"

void f(Explicit<int> x);


// implementation.cpp
#include "header.h"

void f(Explicit<int> x)
{ ... }


This still allows f(42) but gives a compile-time error on f(42.42). It
makes the user code here clearer (IMHO) and avoids making the user
function "f" a template.



I still would not say that some kind of explicit function argument
syntax is without merit - but certainly it would need strong motivation
when there are existing methods of achieving the same effect. The key
benefits of the hypothetical explicit function arguments above are that
it would be convenient in the language, and that it could work with
existing definitions of functions - only the declaration is changed.