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

Why can't VTTPs be other than auto? #43

Open BengtGustafsson opened 1 year ago

BengtGustafsson commented 1 year ago

Clarify or change the sentence that we can't have VTTP other than auto. At some point I had a faint notion of why, but in P2008 a bool VTTP is presented as the prime example (predicate metafunction). So now it seems that the limitation to auto was contravariance showing up again.

On the other hand we must decide what happens if a template taking for instance a bool VTTP gets instantiated with a non-bool VTTP To me it seems that what should be enforced is that the specializations that the template actually create of its VTTP are bool, it doesn't matter what it says on the box. This is consistent with how we have to disambiguate vector::iterator to type even though the compiler knows that in the base case it is a type. If we don't we can still instantiate with a vector specialization for some T where iterator is a value.

If we don't even enforce this then the type is meaningless, and should be auto not because it's the only option but because it doesn't matter what type you put there (except maybe void), you can still instantiate with any variable template that has a suitable template parameter list, and the code generated for a specialization will have to make do whatever type the created VTTP instance has, or it is a late compilation error.

mpusz commented 1 year ago

I am not sure why there is a limitation for auto only in the paper. If we can have bool, int, or auto for the NTTP parameter, it seems reasonable (and doable) to have their templated versions as well, right? I thought you discussed this in the meeting I missed.

BengtGustafsson commented 1 year ago

This came directly from Corentin's proposal on concepts as template parameters I think. There was a short discussion but I forgot the rationale, so that's why I asked.

atomgalaxy commented 1 year ago

The rationale is that specializations of a VTTP are not actually controllable to the point where you can enforce their type:

template bool var = true; template <> float var<std::vector> = 0.2f; <-- you're done

Basically it's impossible to enforce, so it makes no sense to specify.

On Thu, Sep 22, 2022 at 8:27 PM Bengt Gustafsson @.***> wrote:

This came directly from Corentin's proposal on concepts as template parameters I think. There was a short discussion but I forgot the rationale, so that's why I asked.

— Reply to this email directly, view it on GitHub https://github.com/atomgalaxy/isocpp-universal-template-param/issues/43#issuecomment-1255457455, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA5R5O6GBB6C22T5Q7F3FTV7SXILANCNFSM6AAAAAAQRORVAA . You are receiving this because you are subscribed to this thread.Message ID: <atomgalaxy/isocpp-universal-template-param/issues/43/1255457455@ github.com>

BengtGustafsson commented 1 year ago

Such type changes would just cause a phase 2 error when trying to instantiate for vector, I would say.

template<template bool b> class MyClass { bool bb = b<vector>; };

MyClass v; // Could be error as the contract of providing a bool VTTP or it could set bb true as 0.2f != 0.

I don't see this as a good enough reason to forbid VTTPs of a specified type, but we must specify if we want an error if the type is wrong for a particular specialization of the provided variable template, or if we want the compiler to just try to use it anyway.