HaxeFoundation / haxe-evolution

Repository for maintaining proposal for changes to the Haxe programming language
111 stars 59 forks source link

Idea: Implicit object null test #21

Closed anissen closed 7 years ago

anissen commented 7 years ago

I find myself writing a lot of statements of like the following:

if (obj == null) ...
if (obj != null) ...

Personally, I think it would be great to be able to simply write the following to make a object null test.

if (obj) ...
if (!obj) ...

What do you think; is this a good or a bad idea? And is it even possible without violating the language design?

Gama11 commented 7 years ago

This has been discussed before:

https://groups.google.com/d/msg/haxelang/ntmHF4BJlnQ/tciD6QOYUPwJ

kevinresol commented 7 years ago

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){}

nadako commented 7 years ago

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).

markknol commented 7 years ago

Would it be possible to have null coalescing, ?? https://www.dotnetperls.com/null-coalescing

return _language ?? "Haxe"
nadako commented 7 years ago

@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.

anissen commented 7 years ago

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#.

anissen commented 7 years ago

I'll close this issue as this feature does not appear feasible at the moment.