The question is in the title, why :
return double.IsNaN(0.6d) && double.IsNaN(x);
Instead of
return (0.6d).IsNaN && x.IsNaN;
I ask because when implementing custom structs that have a special value with the same meaning as NaN I tend to prefer the second.
Additionally the performance of the property is normally better as it avoid copying the struct on the stack to call the IsNaN static method (And as my property isn’t virtual there is no risk of auto-boxing). Granted it isn’t really an issue for built-in types as the JIT could optimize this easilly.
My best guess for now is that as you can’t have both the property and the static method with the same name in the double class they favored the java-inspired syntax. (In fact you could have both as one define a get_IsNaN property getter and the other an IsNaN static method but it will be confusing in any .Net language supporting the property syntax)
Interesting question; don’t know the answer – but if it really bugs you, you could declare an extension method, but it would still use the stack etc.
It would be nicer (for the syntax) if C# had extension properties, but the above is about the closest you can get at the moment, but it should ‘inline’ quite well anyway.
Update; thinking about it, there is another difference between static and instance; C# always calls instance methods with ‘callvirt‘ rather than ‘call‘, even if ther type is sealed an non-nullable. So perhaps there is a performance benefit from having it static? Luckily, extension methods still count as static, so you get to retain this behavior.