All I am saying is that alias templates are not as transparent to type deduction as written in your first response.

Then why allow the usage of dependent types in alias templates and allow something like std::type_identity_t?

Nicolas



Sent from my iPhone

> On 19 Nov 2021, at 16:43, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>
> 
>> 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