no overrides, and null types #5
Conversation
With parameter defaulting to null, overrides aren't needed, neither of the inline fun nor of the constructor. Also, since weak references could always return null, their generic type should always be nullable.
|
It's a minor difference, but if the type the reference wraps is nullable (which it always should be because weak references could always return null), then, logically, there is no need for the reference instance itself to be nullable. Having a nullable reference wrap a nullable type is somewhat redundant, and necessitates a null check. It seems more canonical to avoid nullability wherever possible. |
There was a problem hiding this comment.
After reading your answer @travisfw I think we should not mix the behavior of the null reference with the public API. If I'm not wrong, the current implementation of this API is designed to avoid the usage of null values. This makes sense because even when a weak reference can return a null value, when creating the weak reference instance it makes no sense to me to initialize it with a null value. At least, it makes no sense to me. That's why the public API does not accept null values but it can return a null instance.
I do not think this is a change we want to add to the project. However, I'm requesting the review of other team members just to ensure I'm not missing something. @Karumi/commanders could some of you take a look?
With parameter defaulting to null, overrides aren't needed, neither of the inline fun nor of the constructor. Also, since weak references could always return null, their generic type should always be nullable.