I found their usage of referential transparency odd at first, too. But as I thought about their reasoning more, it clicked for me. If two numeric bindings are semantically distinguished not by their numeric value in absolute terms, but by their assigned type, you can think of it as if assigning the type is conceptually equivalent to a function call, which returns a value composing the numeric value and the type’s semantics. Eg
let a: Int = 1 // let a = Int(1)
let b: Float = 1.0 // let b = Float(1.0)
Even so, I think this is solvable by:
- De-composing the numeric value for comparison only
- De-composing and re-composing the numeric value for assignment
If you can’t do either, i.e. because one underlying value is inherently incompatible with the other in some way, then you have a static type error regardless of how your semantically distinct types interact.
- De-composing the numeric value for comparison only
- De-composing and re-composing the numeric value for assignment
If you can’t do either, i.e. because one underlying value is inherently incompatible with the other in some way, then you have a static type error regardless of how your semantically distinct types interact.