search

atomgalaxy / isocpp-universal-template-param

We propose a way to spell a universal template parameter kind. This would allow for a generic apply and other higher-order template metafunctions, and certain typetraits.
https://atomgalaxy.github.io/isocpp-universal-template-param/d1985r0.pdf
2 stars 2 forks source link

Run our examples on Circle #8

Closed mpusz closed 1 year ago

BengtGustafsson commented 1 year ago

Message ID: @.***>

This is valid C++:

template auto f(T x) { return x; }

template auto f(float y);

See: https://godbolt.org/z/Y3shGsYTe

Even if we don't include UAs this time around so that UTPs can't be declared at namespace scope which is the only place where explicit instantiation is allowed it would be a problem that the same token combination means totally different things in different locations, I think, and it would definitely prevent UAs to use the same syntax as UTPs if introduced later (unless an arbitrary limitation that UAs can't be in namepsace scope is made).

I'm not totally up to speed about the specific issues against P0945R0 but I seem to remember that it supposedly didn't require disambiguation when the name was subsequentely used. This is of course a non-starter, but were there other problems that would affect the UAs I'm promoting, but not the library solution in the proposal? To me it seems that they are totally equivalent in functionality so what UAs buy us is consistency and less typing (as the ::value can't be avoided unless we have UAs!). So there is a word of caution there: If we want to promote UAs in this proposal the "UA as a library feature" example must go.

I have started working on the bike shedding chapter, and included the above problem for the template auto spelling. I will hopefully have a first draft in a PR later today.

Bengt

mpusz commented 1 year ago

fwd<takes_metafunc, takes_metafunc>{}; // error (1) does not produce an error on Circle.

mpusz commented 1 year ago

The following code fails on Circle but it is probably Circle's implementation bug: https://godbolt.org/z/oxT73K34o.

mpusz commented 1 year ago

C<Z1<5>> c1; // Error: T does not match Z1 passes on Circle.

mpusz commented 1 year ago

There is something really wrong with https://github.com/atomgalaxy/isocpp-universal-template-param/blob/master/d1985r3.md#covariance. Should A and B be concepts here?

BengtGustafsson commented 1 year ago

The following code fails on Circle but it is probably Circle's implementation bug: https://godbolt.org/z/oxT73K34o.

I tried to change it to not using variable template overloading, but that didn't help. I also could not interpret this as other than a compiler bug. https://godbolt.org/z/5bz4sYz9G

BengtGustafsson commented 1 year ago

There is something really wrong with https://github.com/atomgalaxy/isocpp-universal-template-param/blob/master/d1985r3.md#covariance. Should A and B be concepts here?

There are several "auto" missing, just like for function parameters you need (or at least gcc wants you) to have auto after the concept name in variable declaration. This acts as a guard against the rhs evaluating to something not fulfilling the concept:

https://godbolt.org/z/ss3fsz57r

#include <concepts>

int foo()
{
    std::integral auto x = 3;
}