C++ Logo

std-proposals

Advanced search

Re: Explicit alias template specialization

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Fri, 19 Nov 2021 10:42:39 -0500
On Fri, Nov 19, 2021 at 10:31 AM Nicolas Weidmann <n.weidmann_at_[hidden]>
wrote:

> Based on your last example, we would get:
>
> #include <vector>
>
> #include <set>
>
> #include <string>
>
>
>
> template<typename> struct no_default_alias3;
>
>
>
> template<> struct no_default_alias3<int> {
>
> using type = std::vector<int>;
>
> };
>
>
>
> template<typename T> using alias3 = typename no_default_alias3<T>::type;
>
>
>
> template<typename T> void bar(T a, alias3<T>) { }
>
>
>
> template<> struct no_default_alias3<float> {
>
> using type = std::vector<int>;
>
> };
>
>
>
> template<> struct no_default_alias3<bool> {
>
> using type = std::set<std::string>;
>
> };
>
>
>
> void foo()
>
> {
>
> bar(1.0f, std::vector<int>{});
>
> bar(true, std::set<std::string>{});
>
> }
>

IIUC, you've just renamed `std::identity` to `no_default_alias3` and left
everything else the same; is that right?
So your `no_default_alias3` template is serving as a "type deduction
firewall," in the same way as `std::identity` does today.
And in particular, it is *not* acting in the same way as an alias template
does today (because aliases do not serve as firewalls).

I think we're now going around in circles, but just in case, let me show
you a program that directly compares the (transparent) behavior of aliases
with the (firewalling) behavior of non-aliases.

template<class T> using Alias = T;
template<class T> struct Nonalias { using type = T; };

template<class T> void take_alias(Alias<T>); // OK, equivalent to void
take_alias(T); T is deducible
template<class T> void take_nonalias(typename Nonalias<T>::type); // OK,
but T is not deducible

int main() {
    take_alias(42); // OK, T=int
    take_nonalias(42); // does not compile, T can't be deduced
}

My impression of your original message/proposal is that you don't
understand this fundamental difference between aliases and nonaliases, and
you're basically proposing that either (1) some-or-all kinds of aliases
should behave more like nonaliases, or (2) it should be possible to define
(certain kinds of) nonaliases using a slight variation of alias
syntax (instead of using the existing nonalias syntax).

HTH,
Arthur

Received on 2021-11-19 09:42:52