On Fri, Nov 19, 2021 at 5:13 PM Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> Yes, they are.
> Dependent member types are (always?) non-transparent "firewalls" against deduction, but aliases are never(!) firewalls.

If type aliases could be specialized as he proposed, then type aliases
specializations with dependent template arguments would indeed become
`firewalls` in all cases except that they could be matched one to the
other (as in the example from my previous message `alias<T>` would
match to `alias<int>` giving `T = int`).

In the same way, it's possible to extend TAD such that dependent
member types could be matched.
So for example:
`P = typename T::foo` and `A = X:: foo` -> `T = X`
`P = typename foo<T>::bar` and `A = foo<int>::bar` -> `T = int`

This would also require us to preserve member lookup sugar.

This would not be a good idea because of the amount of existing code
which would be broken, but it is possible if we are talking in the
realm of hypothetical language extensions.


> template<class T> using A1 = T*;
> template<class T> using A2 = std::vector<T>&;
> template<class T> using A3 = std::vector<T>::iterator;
> template<class T> using A4 = std::identity<T>::type;
>
> template<class T> void a1(A1<T>); // transparently equivalent to `a1(T*)`
> template<class T> void a2(A2<T>); // transparently equivalent to `a2(std::vector<T>&)`
> template<class T> void a3(A3<T>); // transparently equivalent to `a3(std::vector<T>::iterator)`
> template<class T> void a4(A4<T>); // transparently equivalent to `a4(std::identity<T>::type)`
>
> In a1 and a2 (no matter which syntax you use to write them), the function parameter contributes to deduction of T.
> In a3 and a4 (no matter which syntax you use to write them), the function parameter won't contribute to deduction of T, because there's a "firewall" dependent member type involved.
>
> HTH,
> Arthur
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals