Void isn't quite right though. It corresponds to "return, but with no useful information", which isn't the same thing as not returning at all.
It's the difference between an empty tuple and a thrown exception. On 15 October 2012 13:47, Casper Bang <[email protected]> wrote: > Yes, java has no type that represents "there is no value that is this >> type, not even 'null'". It would be cool if this type existed; a method >> that had this as return type cannot actually return, ever. It has to exit >> abnormally: >> > > From a programmers perspective, when you return from a method (byte-code > 0xb1), you are indeed returning nothing. From the JVM's perspective, you're > not returning anything either - the stack is left completely untouched. > > >> Either it runs System.exit(0), which should probably at that point return >> this special Nothing type (so that you can type: return System.exit(0)), or >> it has to throw an exception. There are no other ways out. >> >> Unfortunately, introducing this kind of concept is exactly the kind of >> thing java does NOT do >> > > Except when it DOES do so, such as when you omit an explicit return and > rely on javac to implicitly paste this in for you at while desugaring. > > >> That's the kind of thing where java has decided that the practical upside >> of having a 'Nothing' value is not actually that much; it's largely >> academic, and it definitely "feels bad" that the language is not complete, >> and that this awesome concept is not actually in your language. However, >> adding it to the language definitely incurs a cost: The compiler needs to >> do all sorts of things to treat Nothing specially, and this is going to >> make the spec much more complicated. >> > > Complications usually arise from the convoluted interactions of > accumulated features (const vs non-const i C comes to mind), not from being > consistent about the programming model up-front. Frankly, I couldn't care > less about how the compiles does things internally, but I am often forced > into this. Another example where this applies, is with generics and the > (for the uninitiated) odd inability to implement Comparable<Fruit>, > Comparable<Veggie> > > >> Sounds ugly. Yet, java's popularity and the robustness of java-based apps >> like google ads and many a server out there suggest it's fine. >> > > You're grasping for straws here. I think we can agree it's not quite that > simple. > > >> Right. I'm saying, well, the jury is still out on this. Is it actually >> right to burden your language with the Nothing concept? >> >> I'm pretty sure that retrofitting Nothing onto java is a grave mistake at >> this point. >> > > But we already have Void, the compiler probably already uses plenty of > places internally. Promote it to work in tandem with javac's existing > desugaring rules, such that a return Callable<Void> results in a non- > stack-modifying return which satisfies developer, compiler and JVM. > > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
