Should we have an Embeddable trait?

[ben-laird]

A lot of times, you can have a super-type that can be downcast to a sub-type if the right conditions are met. Some examples include:

1. You can convert a real number to an integer if the real number ends in ".0"
2. You can convert a complex number to a real number if the complex number has an imaginary component of 0
3. You can convert an enum into an instance of an enum variant if and only if the underlying variant of the enum matches. I do this in my rendition of Rust enums in TypeScript.
4. You can convert an array to an n-tuple if and only if the length of the tuple is n
5. In TypeScript, you can cast a type into a sub-type if that sub-type matches a given predicate

Something as strong as example 5, or really this entire proposal, should not be considered lightly though, since it may introduce type soundness errors. We may think these potential problems, like an Embeddable impl not properly verifying what it's supposed to, can be counted as user error and thus not a soundness error; Rust does this with the PartialEq family of traits, the PartialOrd family, and Hash. Some other problems that I don't know of, we might not be able to wave off to user-land. Any TypeScript-inspired feature like this one should be looked at with a bit of scrutiny, since TS is known to be an unsound type system.

[FyreByrd]

This would be distinct from the From/Into traits yes? Are From/Into considered lossy or lossless? If lossless, I feel like this would be the same? But maybe I don't understand the distinctions...

[ben-laird]

This would be distinct from the From/Into traits yes? Are From/Into considered lossy or lossless? If lossless, I feel like this would be the same? But maybe I don't understand the distinctions...

@FyreByrd that's a really good point, I didn't think about that. I think From and Into can be "lossy" in the sense that they don't have to represent subjective maps (or even injective maps, since multiple input values with the same Into impl could map to the same output value). On top of that, and why I think that's a really good point, is that Embeddable should be an injective map, but now that I think about it Embeddable doesn't really have to be injective. Making Embeddable non-injective then almost entirely makes the Embeddable trait redundant, for the reasons you mentioned.

That said, I do think instead of having the Embeddable trait, we should have markers for From and Into (or maybe even any function) that assert that the implementation is 1-to-1 and onto (nothing gets mapped to the same value and all output values have an input value that gets mapped to that output value, respectively). I think that would be especially useful for compiler optimizations, but you know way more about compiler optimizations than I do.

[FyreByrd]

Gotcha. So, for example, floating point numbers with From/Into for string, should be onto? But then floating point numbers with From/Into for integers would not be, correct?

[ben-laird]

1. If you can represent every possible string as a floating point number, then yes, conversion from floating point numbers to strings is onto
2. Exactly, conversion from floating points to integers is not onto, because there are floating point numbers (real numbers) that can't be represented as an integer