Date: Fri, 19 Nov 2021 17:36:09 +0100

pt., 19 lis 2021 o 17:28 Matheus Izvekov via Std-Proposals

<std-proposals_at_[hidden]> napisaĆ(a):

>

> 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`

You can't go back from `bar` to `foo<T>` as `foo<T>::bar` is turing

complete, you would need to check every possible `T` to find a one

matching `bar`.

Simple example:

`P = typename T::foo` and `A = int` how to find `T` then?

>

> 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 mailing list

> Std-Proposals_at_[hidden]

> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

<std-proposals_at_[hidden]> napisaĆ(a):

>

> 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`

You can't go back from `bar` to `foo<T>` as `foo<T>::bar` is turing

complete, you would need to check every possible `T` to find a one

matching `bar`.

Simple example:

`P = typename T::foo` and `A = int` how to find `T` then?

>

> 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 mailing list

> Std-Proposals_at_[hidden]

> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2021-11-19 10:36:22