NaN is really a problem only because of using it as an acronym rather than just having .invalidNumber or .notANumber (little uglier) or something similar instead. This comes back to the annoying consideration between something being prior art, at the cost of potentially defining something that’s better, or a better fit for the language. If NaN didn’t exist elsewhere, would we even consider it at all if we were implementing float point numbers for the first ever time in Swift? I’d prefer we defined something more verbose as an alternative to avoid the acronym entirely.
When it comes to having iPad conformance the question is; should we ever actually test for names at all? An iPad is a brand, it’s not really something that a program should test for, as what’s important to a program are capabilities. The same is true with testing for an OS, we don’t want to test Windows, Mac etc., but rather to test what libraries are available. Same is true with hardware; it doesn’t matter if a device is an iPad, what matters is that it has a touch-screen rather than a keyboard, that it has a small screen rather than a full monitor, that it’s mobile (and not plugged in) etc. Testing for names like that should be avoided at all costs when it comes to variable and method names, and be relegated to string-based tests for when you absolutely have to access that information. In other words programs should be platform agnostic, and only need to know whether capabilities they require or optionally support exist or not. For these I’d prefer that the guidelines warn against these in the strongest possible terms, as they’re usually a bad idea IMO. > On 5 May 2016, at 20:49, Justin Jia via swift-evolution > <[email protected]> wrote: > > I think ipad and IPAD are better. Ipad and IPad look really bad. > e.g isIPAD / ipadUser / isNAN / nan > > Or what about this: For lowerCamelCase, we use all lower letters (like ipad). > For UpperCamelCase, we keep the original one (iPad). > e.g. isiPad / ipadUser isNaN / nan > > Justin > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
