On Monday, October 15, 2012 2:47:55 PM UTC+2, Casper Bang 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. >
The compiler will refuse to compile 'return;' in any method with a non-void return type, and the verifier will refuse to run a class if you hack that into the bytecode. "From the JVM's perspective" is therefore misleading; at best you can speak 'from the verifier's perspective', here, which will simply note that there is a discrepancy between return type and variant of the return opcode used and deny the class. I don't think this is particularly relevant to this discussion. > > >> 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. > You're comparing apples and kitchen sinks. > 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. > You're 'often' forced into having to hand-hack some Nothing into your code? I call baloney. > Another example where this applies, is with generics and the (for > the uninitiated) odd inability to implement Comparable<Fruit>, > Comparable<Veggie> > Another: Yup, that's annoying... once in 5 years case. > > >> 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. > You just mentioned Comparable<Fruit> and Comparable<Veggie>. Who is grasping at straws here? Sure, this isn't simple. That was kind of my point, too: Yes, 'nothing' is a real concept and it is one that java simply does not have. It would be simple to say: "... well, then, let's add it!", but I was trying to highlight how its (probably) not worth doing, and either way it is a tradeoff: There are also signficant (At least, relative to the mediocre upside of adding this to the language) downsides to adding it. > > But we already have Void, the compiler probably already uses plenty of > places internally. > java.lang.Void and the Nothing concept do not intersect much. There's a big difference between 'non-magic class that is, by consensus, accepted as a placeholder for "forget about the return type, it doesn't mattter"' and actual room in the spec, compiler, toolchain, and programmer's head for the nothing concept. > 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. > ... Leads down the path of the disadvantages. I'm with Ricky on this one: More serious use cases please. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Ern-A_JXRdAJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
