Rémi Forax's Blog

Function that does not return normally II (the return)

In a previous entry, i've written about declaring a method that doesn't return normally using null, the type of null, as return type. A comment from Neal Gafter make me realize that i was wrong but i now think the closure spec is wrong too.

What the closure proposal says is that a function that doesn't return normally should use null. Not the converse, so i agree with neal that a method that use null as return type doesn't allow the compiler to flag the method as "never returned", perhaps the method always returns null.

But the closure proposal is wrong too, if a function that never returns is typed null its function type can't be a subtype of the type of a function that returns a primitive type.
So the example below will not compile :

 null(void) f={
   throw RuntimeException();
 };
 int(void) g=f;

The assumption of the closure proposal is that a function that never return has a return type that is a subtype of null. This is clearly wrong with the current Java type system because boxing relations are not subtyping relations.

I propose to introduce throws as the return type of a method that never returns, with the following subtyping rules :

 Object < Integer < null < throws
 and
 int < throws

Using throws as several avantages upon null for method that doesn't return normally because :

1. a function that returns throws is a subtype of a function that returns a primitive type.
2. users can declare methods that doesn't return normally and the compiler can understand that.

I wait your comments.

Comments

• Well, I agree that the closure proposal is wrong... ;-)

  Posted by: tobega on September 08, 2006 at 07:19 AM

• Interesting idea. The subtyping of function types that you get naturally is the primary difference between the current proposal (based on function types) and the interface-based one that I'll blog shortly. The interaction between primitive types and subtyping has always been a thorn in Java's side. Java already has the null type and subtyping rules for it, it just isn't named in the surface syntax. Certainly it would be helpful to have a type that means "you can't get here", (its standard name is "bottom") but I don't think that needs to be done at the same time as closures; it is an upwardly compatible change. The same issues arise today for covariant returns.

  Posted by: gafter on September 08, 2006 at 09:13 AM

• Rémi pointed out to me in private email that it isn't compatible to add bottom later. We've added bottom to our working draft.

  Posted by: gafter on September 12, 2006 at 07:33 AM

This work is licensed under a Creative Commons License.