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