archives

Implicit conversion (subtyping) vs Explicit conversion

In the design discussions for Zen, (see: http://lambda-the-ultimate.org/node/5376) we have hit an important decision point, and I wanted to get opinions from the PL community about what they think is the best approach. The choice is between:

- Implicit conversions with explicit invariance
- Implicit invariance with explicit conversions

By way of an example, given a type like this Set<Int>|Set<Float> we could implicitly convert it to Set<Int|Float> where required (so Set<Int>|Set<Float> <: Set<Int|Float>.

- Could this cause problems where the fact that all types in the collection must be the same is a property relied upon by an algorithm.
- How does this interact with mutability? Is it only sound to implicitly convert with immutable collections?

Then there is the question of boilerplate. With implicit conversion we need an annotation to say 'do not implicitly convert', in contrast by forcing explicit conversion we need an annotation (function call) to do the conversion.

- Which option results in the most boilerplate depends on how often the situations occur. Do people find they are wanting to convert types (subsumption/subtyping etc) more often than they are wanting types to remain fixed.

I would greatly appreciate views from the community on their experiences of designing languages with these features, or using languages with either approach.