You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently this library is limited to basic numeric types (f*, i*, u*). Should it remain that way?
std::num::NonZeroU32 etc. are essentially numeric types. So should we support those?
What about numeric and vector types for third-party libraries, behind feature flags?
With a few lines of code we can support tuples ((A, B) → (C, D) where A → C, B → D, also for more elements to some limit) and arrays ([A; N] → [B; N] where A → B). It's easy to add, but may impact compile times.
Concern: casting as an operation is expected to be transitive: if a → b and b → c then a → c. Supporting additional "numeric" types such as NonZero* is therefore a substantial increase in the number of conversions we must support.
(We cannot have this automatically since the type of b must be specified.)
Concern: properly casting between types from multiple third-party libraries could quickly become over-complex.
Concern: there is significant appeal in a small, minimal-dependency library.
Given the above, easy-cast will likely remain limited to standard types. Supporting arrays and small tuples may be desirable.
The text was updated successfully, but these errors were encountered:
Decision: do not support NonZero* types (at least for now). It's a lot of additional casts and I don't have a use-case (although I don't have a problem with someone else making a PR covering NonZero* types similar to how From does, provided it's well tested).
Decision: do try to support third-parties implementing this crate's traits. For now, don't add any such support from here.
Decision: do implement some conversions on array/tuple types.
Currently this library is limited to basic numeric types (
f*
,i*
,u*
). Should it remain that way?std::num::NonZeroU32
etc. are essentially numeric types. So should we support those?(A, B) → (C, D) where A → C, B → D
, also for more elements to some limit) and arrays ([A; N] → [B; N] where A → B
). It's easy to add, but may impact compile times.Concern: casting as an operation is expected to be transitive: if
a → b
andb → c
thena → c
. Supporting additional "numeric" types such asNonZero*
is therefore a substantial increase in the number of conversions we must support.(We cannot have this automatically since the type of
b
must be specified.)Concern: properly casting between types from multiple third-party libraries could quickly become over-complex.
Concern: there is significant appeal in a small, minimal-dependency library.
Given the above,
easy-cast
will likely remain limited to standard types. Supporting arrays and small tuples may be desirable.The text was updated successfully, but these errors were encountered: