You could formulate your proposal in a weaker form, where the type is used for direct code, but not for template parameters.   If for template parameters the underlying type is used, it would be a std::vector<float> all along, and elements taken from the vector would be float, not subtype.   Then also the advantages of the subtypes could not be used, when using the container.   -----Ursprüngliche Nachricht----- Von:Karafiát, László via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 02.09.2024 23:53 Betreff:Re: [std-proposals] Fwd: Standardised Type Punning API for Wrapper Types An:Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>; CC:Karafiát, László <laszlo_at_[hidden]>; Well, the subtype of a float for example would automatically be 'converted' to float or double (i.e. 'seen' as such when needed) by the compiler. Except if you overload or hide that cast in your subtype definition. Would this not help? On 2024-09-02 20:06, Sebastian Wittmeier via Std-Proposals wrote: > Would it? > > The sub-types would be different types in the type system, and so would > be the templated container classes, wouldn't they? > > Or would the proposal <Scalar Inheritance> use the scalar type for > templates? > >     -----Ursprüngliche Nachricht----- >     *Von:*Karafiát, László <laszlo_at_[hidden]> >     *Gesendet:*Mo 02.09.2024 18:43 >     *Betreff:*Re: [std-proposals] Fwd: Standardised Type Punning API >     for Wrapper Types >     *An:*std-proposals_at_[hidden]; >     *CC:*Sebastian Wittmeier <wittmeier_at_[hidden]>; >     Hi, > >     my proposal <Scalar Inheritance> would allow sub-typing (instead of >     wrapping) scalar types. Would that be not a clearer and better solution? > >     László > >     On 2024-09-02 17:07, Sebastian Wittmeier via Std-Proposals wrote: >      > How would you know that the container specialization is different? >      > >      > Or in other words they are always different as it is a template. >      > >      > At least each container would have to support such a facility to >     remove >      > the type by itself. Otherwise the implementation details could hide >      > incompatibilities. >      > >      > std::vector could support a move_to member function: >      > >      > std::vector<my_distance_type> d1; >      > >      > // creates a new d2 with new metadata, but keeps the convertible >     actual >      > data without copying >      > >      > // d1 is empty afterwards >      > >      > std::vector<double> d2 = d1.move_to<double>(); >      > >      > > > > -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals