niedz., 3 lip 2022 o 15:55 Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Sun, Jul 3, 2022 at 8:49 AM Bo Persson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On 2022-07-03 at 14:02, Frederick Virchanza Gotham via Std-Proposals wrote:
> > >
> > > Earlier this year on 25 March, I shared my idea to this mailing list of
> > > using the 'explicit' keyword on template parameters as follows:
> > >
> > > template<explicit class T>
> > > void Func(T &arg)
> > > {
> > > /* Do Something */
> > > }
> > >
> > > The idea was that you would have to write:
> > >
> > > int main(void)
> > > {
> > > int i;
> > >
> > > Func<int>(i);
> > > }
> > >
> > > because the 'explicit' keyword would prevent automatic deduction of the
> > > type T.
> > >
> > > You can see my original post archived here:
> > >
> > > https://lists.isocpp.org/std-proposals/2022/03/3721.php
> > > <https://lists.isocpp.org/std-proposals/2022/03/3721.php>
> > >
> > > That same week, another contributor made another suggestion that looked
> > > similar to what I was suggesting, but which was very different in
> > > functionality. My own suggestion I think got lost in the paperwork back
> > > and forth, and so I would like to bring it to people's attention again
> > > now, as I've shared the idea elsewhere and people seeming to be
> > > overwhelming in support of it.
> > >
> >
> > The standard already has type_identity, added specifically for this purpose.
>
> Well yes, but that doesn't make the language feature a priori a bad
> idea. After all, this is an idiom that has to be taught rather than
> something that's easy to look up.
>
> What makes the feature not worthwhile is both that the idiom exists
> *and* that this isn't all that common. That is, while we do need the
> ability to stop a function template parameter from being deduced, it
> doesn't happen often enough to warrant being a language feature if
> there is an alternative that isn't particularly cumbersome to use. And
> `type_identity_t`, while not being very indicative of what's going on,
> is good enough.

Probably only thing we could improve is add alias that have more
descriptive name like:

```
std::explicit_type_t
std::no_argument_deduction_t
```

to be more explicit (pun intended) to what we want there.

For langage solution we would need A LOT more to justify adding it.
Like for `require` that alternative was ugly and less powerful:

```
std::enable_if_t<cond_A, void> f();
std::enable_if_t<cond_B, void> f();
```

if `cond_A` and `cond_B` are true at once you can't use `f` directly,
you need add `cond_B && !cond_A` to break ties.
In case of language feature `require` can examine `cond_B` in case of
concepts and check if there is ordering
between `cond_A` and `cond_B` (like `cond_B == cond_A && X`)

```
template<typename T>
concept TestA = true;

template<typename T>
concept TestB = true && TestA<T>;

template<typename T>
struct K
{
    int f() requires TestA<T>
    {
        return 1;
    }
    int f() requires TestB<T>
    {
        return 2;
    }
};

int main()
{
    return K<int>{}.f();
}
```

Even though both `TestA` and `TestB` are always true, concepts can
determine that the second function is more specific than the first one
and it should be called.

Explicit template parameters do not add anything new to the table. As
they do the same thing as `type_identity_t`.
It's hard to make it have more functionality to justify it as this
proposal is very specific.



> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals