[FEATURE] Consider convert accepting wide targets
jtlap opened this issue · 9 comments
Up to now the target parameter of convert must be a "non wide" type
For instance to convert a wide<float, fixed<4>> f to a wide<double, fixed<4>> d one must write
wide<double, fixed<4>> d = convert(f,as<double>()) which is quite good an simple
But if the type of d is only known by its name D the user must write
D d = convert(f, as<eve::underlying_type_t<D>>()) ;
The user does not generally care about eve::underlying_type_t<D> and we propose to defer the work of computing the scalar type to the convert object and the user can also write
D d = convert(f, as<D>());
for the same result.
convert keep the number of lanes of f and uses the underlying type of D in every cases.
I don't understand what's underlying
My big problem with convert(x, eve::as(w)) is cardinal mismatch.
If we enforce same cardinal - maybe.
But ideally it should be a differnt spelling.
like convert(x, eve::as_element(w)) or smth
there is no mismatch involved as the cardinality is only from x an there is no other possible sensible choice that to reproduce the x cardinality
what if convert(x, as<T>) works as described if a is scalar and is SFINAE out if a is wide and cardinal don't match ?
I also like as_element which is trivially
template<typename T>
using as_element = as<eve::underlying_type_t<T>>;
Not sure about SFINAE out, I'd prefer an error message probably. But those are OK with me.
static_assert is fine in my book
So are we OK for having both as_element ans the automatic support with cardinal checks ?
Either of those seem to solve the issue. If you want both - we can have both. Whe should make sure that as_element(x) also works. Can be done with inheritance
Yes, that's where I am heading in fact.
After some other disxussion with jtlap, as_element is enough