3 ms·

TLDR: We always knew null'a could float around and cause NPEs, but many assumed they couldn't convince the compiler to unsafely convert, e.g., a String to an In

TLDR: We always knew null'a could float around and cause NPEs, but many assumed they couldn't convince the compiler to unsafely convert, e.g., a String to an Integer. However, since null can inhabit any type, we can use null as a proof of any proposition, for example that there exists some super type of Integer which is a subtype of String. Of course, if such a type exists we should be able to traffic an Integer to a String. The example on the page is pretty straightforward. I encourage everyone to reason it out.

mjevans 10y ago
I suppose that means that it is 'null' which is evil in Java. If you're going to get rid of pointers, and you still want to have the option of a thing existing or not, you therefore must represent it with a list and a contract on the size of the list. (Zero entities, or one entity in the case of a 'single object reference.) Otherwise you'd only be able to detect 'missing' objects by exceptions being thrown.
- theemathas 10y ago
  I recommend that you read section 6.2 (The Billion-Dollar Mistake) in the linked paper. Most important part of that section: > If our community wants to remove implicit nulls from industry, where appropriate, our community should make greater effort to appreciate the complex compromises that have to be made in practice so that our work can successful transfer out of academia.
- danking00 10y ago
  What you've described is precisely the Optional or Maybe type. Many folks worry about the efficiency, which is reasonable, but feels misguided. A nullable annotation would be sufficient for the safety we all crave and would have no runtime overhead (i.e. It would still represent missingness with null.)
  - lmm 10y ago
    The problem is that then your Optional is a special kind of type that only works on reference types, and you either can't instantiate Optional<int> or it has radically different performance characteristics from most Optionals.
- johan_larson 10y ago
  I can live with the notion of nulls. But I think having all (non-primitive) function parameters be nullable is a huge mistake. It is just very rarely what the writer actually wants. And explicitly checking for null for all object parameters is a huge pain. The right solution, to my mind, would be to have function parameters be non-nullable by default. Unfortunately it is too late in the history of Java to switch to that behavior now. Too much code would break. So I would settle for being able to declare individual function parameters non-nullable as a standard part of the language. I can't believe it would be all that hard to implement.
plaguuuuuu 10y ago
<B extends A> A upcast(Constrain<A,B> constrain As someone who doesn't know Java well, why is it that we need to pass a Constrain<A,B> into the function? We already know that for this method, B extends A
- lmm 10y ago
  To allow B and A to be inferred based on the constrain passed in. Look at where upcast is called - it doesn't explicitly call bind.upcast<Something, Otherthing>(...), it just passes the values.

mjevans 10y ago

I suppose that means that it is 'null' which is evil in Java. If you're going to get rid of pointers, and you still want to have the option of a thing existing or not, you therefore must represent it with a list and a contract on the size of the list. (Zero entities, or one entity in the case of a 'single object reference.) Otherwise you'd only be able to detect 'missing' objects by exceptions being thrown.

theemathas 10y ago
I recommend that you read section 6.2 (The Billion-Dollar Mistake) in the linked paper. Most important part of that section: > If our community wants to remove implicit nulls from industry, where appropriate, our community should make greater effort to appreciate the complex compromises that have to be made in practice so that our work can successful transfer out of academia.
danking00 10y ago
What you've described is precisely the Optional or Maybe type. Many folks worry about the efficiency, which is reasonable, but feels misguided. A nullable annotation would be sufficient for the safety we all crave and would have no runtime overhead (i.e. It would still represent missingness with null.)
- lmm 10y ago
  The problem is that then your Optional is a special kind of type that only works on reference types, and you either can't instantiate Optional<int> or it has radically different performance characteristics from most Optionals.
johan_larson 10y ago
I can live with the notion of nulls. But I think having all (non-primitive) function parameters be nullable is a huge mistake. It is just very rarely what the writer actually wants. And explicitly checking for null for all object parameters is a huge pain. The right solution, to my mind, would be to have function parameters be non-nullable by default. Unfortunately it is too late in the history of Java to switch to that behavior now. Too much code would break. So I would settle for being able to declare individual function parameters non-nullable as a standard part of the language. I can't believe it would be all that hard to implement.

plaguuuuuu 10y ago

<B extends A> A upcast(Constrain<A,B> constrain As someone who doesn't know Java well, why is it that we need to pass a Constrain<A,B> into the function? We already know that for this method, B extends A

lmm 10y ago
To allow B and A to be inferred based on the constrain passed in. Look at where upcast is called - it doesn't explicitly call bind.upcast<Something, Otherthing>(...), it just passes the values.