Should ren::Float be willing to implicitly (or explicitly) cast from a ren::Integer?

[hostilefork]

The current static_cast system is based on casting through the hierarchy of wrapper classes in a way that preserves their bits. You can static_cast a ren::String to a ren::Value, then up to a ren::AnyString, and back to ren::String again.

However, in that process the bits didn't change. For instance, in Red, it was the same RedCell the whole time, just being safely cast through the inheritance hierarchy of the C++ classes.

Should steps be taken outside of this? C++ isn't going to have the same behaviors, like statically checking against a dynamic typeset. But it can have some features Red or Rebol doesn't have, like being willing to implicitly cast a float.

However, it is additional complexity to add such a feature...and perhaps it is more likely to confuse users of the binding than to offer real benefit. After seeing a red::Integer implicitly coerce in the binding (which would involve different bits underneath on the source and target), they may wonder why they can't do this:

foo: func [value [float!]] [
    // ...
]

x: 10
foo x