implicit conversions for Java types

[gavinking]

I have long opposed defining any implicit type conversions in the language, because of the ambiguities and confusing behavior that can result. For example, consider what happens if we define an implicit type conversion from Java List to Ceylon MutableList, and write:

javaObject.someList.size

The programmer might expect size to refer to the attribute MutableList.size of type Integer, but in fact it actually refers to the method size() of List. Even worse ambiguities arise if implicit conversions are transitive.

As we've seen, however, confusion and inconvenience can also arise from not having any sort of implicit type conversions, for example, when Java's String type leaks into Ceylon code, or when strings aren't assignable to Java parameters that accept CharSequence.

Yesterday, I realized that there is an approach to implicit conversions that doesn't lead to the ambiguities I've always been bothered by. Traditional implicit type conversions are only applied when the original type is not assignable to the declared type of something. They are thus, in some sense, "lazy", and the original type always has the chance to "leak out".

But for the specific case of inter-language interop, that's actually not what we need. What if we defined some type conversions that were always applied, as soon as possible? That is, as soon as we have an expression of type java.lang.String, the conversion to ceylon.language::String is immediately applied, and no operations of java.lang.String are ever visible. Then, essentially, no Ceylon code would ever be able to interact with the type java.lang.String except to the extent that it can occur as a type argument in a generic type.

Likewise, no Ceylon code would ever interact directly with a java.util.function.Predicate<T>, since any expression of that type would immediately be converted to Boolean(T).

It seems to me that this solution is perfect for protecting Ceylon code from Java types, including String, primitive wrapper classes, @FunctionalInterfaces, Iterable, List, Set, Map, and perhaps even primitive arrays (which could be converted to Array). I think and hope it would also work for the special transformation CharSequence <-> List<Character>, which I admit is a slightly tricky case.

So the next problem that arises is how to pass a value to a Java parameter declared with one of these "hidden" types. Since we can no longer form an expression of type java.lang.Integer, we can't call any Java method that accepts a java.lang.Integer.

Well, the solution is quite similar: the typechecker, when it comes to assign a type to parameter of one of the "hidden" types, actually applies the same conversions, and arrives at a type to which we can assign!

Obviously, this implies a mathematical property of the transformation, namely that it is a bijection. Fortunately, I think we can shoehorn our transformations into a bijective function. However, I still need to verify that.

For this to really work correctly and transparently, there's one big caveat: the set of transformations and reverse transformations would need to be applied every time we assign a supertype like Object or Number to or from Java! Actually CharSequence also counts as one of these "supertypes", so it's not that special. As is Iterable I guess.

Anyway, I think this is a very strong way forward, and just requires thinking through the details. I believe it can be made to work.

WDYT?

[bjansen]

What happens if you need to pass a j.l.String to a Java method that accepts an Object?

[lucaswerkmeister]

Does this mean that it’s no longer possible to use j.l.String at all? What if you want to iterate over chars, or use methods without equivalent like String.matches? And does this turn javaString into an identity function?

[gavinking]

What happens if you need to pass a j.l.String to a Java method that accepts an Object?

As I said above:

the set of transformations and reverse transformations would need to be applied every time we assign a supertype like Object

You would assign a Ceylon String and it would be converted.

[jvasileff]

IIUC, this proposal kicks the can down the road by making it easy to use a JList<JString> as a MutableList<String>, but it doesn't help with adding a MutableList<String> to a JList<JList<JString>>. Likewise, it doesn't solve the problem of calling a function that accepts a JList<JString>.

I think a valid an interesting question is, "how far should the can be kicked?"

Today, it is sometimes difficult to know whether javaString is necessary without the IDE's help, since the model loader's help depends on whether or not a function was defined generically (e.g. a JList<JString> is different from a JStringList implements JList<JString>). This proposal would help with this, but in turn, requires developers to "start" understanding interop issues one level deeper.

[gavinking]

Does this mean that it’s no longer possible to use j.l.String at all? What if you want to iterate over chars, or use methods without equivalent like String.matches?

Correct. You could use static methods of java.lang.String, and you can use Java's Pattern class, of course, but instance methods of java.lang.String could not be called.

Perhaps you could do it using this syntax:

value charArray = String.toCharArray(string)();
value bool = String.matches(string)(pattern);

But frankly, that's a bit obscure.

And does this turn javaString into an identity function?

Right. There would be no use for functions like javaString() with this feature.

[gavinking]

IIUC, this proposal kicks the can down the road by making it easy to use a JList<JString> as a MutableList<String>, but it doesn't help with adding a MutableList<String> to a JList<JList<JString>>. Likewise, it doesn't solve the problem of calling a function that accepts a JList<JString>.

That's right. In principle, I think you could define a bijective transformation which did recursively replace types like X<Y<JString>> with X<Y<String>>. However, I think it would be very difficult to actually implement that transformation at runtime.

[gavinking]

For the record, I don't think it's at all common to encounter types like List<List<String>> in Java APIs. Surely they occur occasionally, but I don't think they're a frequent-enough occurrence to be a real problem.

[gavinking]

To be clear about what this proposal really is: it generalizes the existing type transformations that the model loader already does, in two dimensions:

• from type schemas, to type instantiations, and
• from only primitive types, to certain other Java "object" types.

Doing the transformations in the model loader is "easy" from a certain point of view, bit falls apart when we instantiate a generic type with a type we want to transform. This is the fundamental source of the long-running disagreement between myself and @FroMage over where is the right place to do this.

What I'm now saying is that, indeed, Stef was right all along, and indeed the transformation belongs in the typechecker, but that it's not an "implicit type conversion" in the traditional sense. Instead it's a mapping between types of the sort that we have previously only thought of doing at the model loader level.