Date: Fri, 19 Nov 2021 17:27:56 +0100

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

<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

Received on 2021-11-19 10:28:37