Closed anissen closed 7 years ago
This has been discussed before:
https://groups.google.com/d/msg/haxelang/ntmHF4BJlnQ/tciD6QOYUPwJ
abstracts will help you:
https://github.com/haxetink/tink_core/blob/0b6335e/src/tink/core/Pair.hx#L13-L17
and you write if(pair){}
or if(!pair){}
I don't think that would play well with type inference and it reads like it's a bool, not a nullable object. so I'm against it.
If you have to work a lot with nullable values, consider using an abstract like this which you can augment with operator overloading from @kevinresol's example (also maybe a postfix !
for unwrapping).
Would it be possible to have null coalescing, ??
https://www.dotnetperls.com/null-coalescing
return _language ?? "Haxe"
@markknol that probably would be possible, but this is part of a bigger discussion about what we want to do with Null<T>
for Haxe 4.
Thanks for all the feedback thus far, much appreciated!
@kevinresol: abstracts will help you:
Thanks for the link -- abstracts are awesome! However, this solution would require wrapping all my nullable objects in abstracts which of course is doable but not a convenient or elegant solution in my opinion.
@nadako: I don't think that would play well with type inference and it reads like it's a bool, not a nullable object. so I'm against it.
With respect to the type inference argument: I don't know enough about how the type inference works in the compiler to argue one way or the other here. Nicholas also mentioned this issue in the old discussion hereof. If this indeed is a problem then I guess implementing this idea in the language might not be possible at all.
With respect to it reading like a bool: I've been using smart pointers in C++ for years and they allow for the same if (obj) ...
-syntax. Confusing objects and bools has never been a problem in our sizeable codebase. Also, must IDE's ought to show the type upon inquiry with the new display features (if the type can be correctly inferred, that is).
@markknol: Would it be possible to have null coalescing, ??
Null coalescing would be really great to have too! I would love to be able to use obj ?? other_value
and if (obj?.property) ...
but (as far as I can tell) you cannot use null coalescing to do something like if (obj?) ...
in C#.
I'll close this issue as this feature does not appear feasible at the moment.
I find myself writing a lot of statements of like the following:
Personally, I think it would be great to be able to simply write the following to make a object null test.
What do you think; is this a good or a bad idea? And is it even possible without violating the language design?