Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hey, don't knock it! Maybe I want a null reference to an Optional<int> to mean something different than a non-null reference to an optional that contains a null reference to a boxed Integer.

Database theory tells us that having multiple null values is useful ("eh, I don't know" vs "your question has no meaning").

Seriously though, it would be great if they just added a "non null reference" type to the language. C++ has this, and it is useful (even though the compiler doesn't enforce the non-null bit).

The thing that always irked me about Optional<T> is that they are synonymous with bare Java references (which also can be null, at least according to the language spec / compiler). It is like a Java version of

#define THIS_PROGRAM_IS_WRITTEN_IN_C *

to my eyes.

To each their own.



Eh, in that case you should roll your own container type appropriate to the business logic, e.g. DBWriteResult<T> (or return Optional<Optional<int>>, but probably not that)


clang will(at least v4 will) tell you you did a silly thing if it can reason that your a statically binding a reference to nullptr. int & i = (int)0;

Not sure how far it can go down the rabbit hole though. This is really where value types/regular types are really nice.

I think it would have been better for Java to allow the flatmap like stuff for any reference instead of creating an optional. But I am not a fan of either for when there is no value due to error conditions. There are optional values and there are errors that prevent the fulfillment of the contract. So either throw so something can be done or return a class that can either be an error or the value. But returning null does not allow the caller to act on it.

You are so right though about non-null references. I would go further and say nullable should not have been the default but an added keyword. That is the trait of a c++ reference I like. Just use it and don't check for null. With that Optional can have some differentiation and is meaningful for situations where an error hasn't occurred.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: