grauzone wrote:
Don wrote:
In D some people have proposed to change the semantics of the "is"
operator, to make it more useful and tidy, so if you want to know if
x is a NaN you can then write if(x is nan).
That won't work in this case, unless you make nan a keyword. There are
2^^62 different NaNs, so a bitwise comparison will not work.
There are other cases where if and is seem to do non-obvious things,
that can lead to subtle bugs. If "x" is an array, if(x) checks if the
array descriptor is null, and not whether x has length 0.
To be consistent, I see two choices how this could be fixed:
1. "if" is "intelligent", then both the float and the array case should
be fixed to do what one would expect
What would you expect? For floats, I don't think there's ANY choice that
makes sense.
2. just turn if(x) into if(x is x.init) and make "is" a bitwise
comparison even for floats
If way 2. is chosen, I don't think multiple NaN would be a problem. The
programmer just has to be aware that NaN isn't a single value.
Surely you mean if (x !is x.init) ?
Won't work for structs.
But why bother? If you know that if (x) is true, how does that help?
It's not float.init, but it still might be float.nan.
You still need a seperate nan test!
"is" yields true if the value is exactly the same, and nothing else. In
conclusion, if(x) would be about as useless for floats as it is for
arrays. In any way, the situation wouldn't be worse than before, but at
least more consistent.
I really don't think there's a solution. The only thing that makes sense
is to disallow it completely.
But more importantly, I cannot see any reason to try. I cannot see any
reason why the if (x) syntax is desirable for floats. I can see many
downsides and opportunities for bugs, but I cannot see ANYTHING good
about it at all. It's a silly thing to have in the core language.
We don't need it. Get rid of it.
