Furthermore, YES/NO in Objective-C is not the same as true/false in Swift: I'm always watching out for code that checks if a BOOL value is YES, because YES just isn't the only true value in Objective C. The following code has a subtle bug in Objective-C whereas it works nicely in Swift. (One could also argue that the bug is in the code that produced bogus x/y-values in the first place, but anyhow.)
if(x || y) { if(x == y) { print("x and y are both true") } else { print("only one of x and y is true") } } else { print("x and y are both false") } Of the three print()-statements above, 2 are wrong in Objective-C, and only the last one is true. E.g. if x is YES and y is 2, Objective-C will print "only one of x and y is true". That's at least counter-intuitive, and once you spend an hour tracking down a bug related to it you'll appreciate a real Bool type that can really only be true or false, and nothing else. (Sure, booleans should only be YES or NO in Objective-C, and IMHO the culprit are usually implicit (or even explicit!) conversions from int or char (or id) to BOOL.) The Bool-semantics of Swift are the same as Java's, so I think it makes sense to call the literals true and false also. -Michael > Am 04.05.2016 um 21:51 schrieb Robert Widmann via swift-evolution > <swift-evolution@swift.org>: > > I am a soft no on this if only because it seems unnecessary to augment such > well-defined and meaningful constants to match Objective-C [e.g. we’re > subject to the same set of “why does Swift use YES and NO when it already has > true and false” questions that exist if you search around for “YES NO > Objective-C”]. Plus, if you want your own private definition of truthiness, a > couple of let constants can cook up a DSL just fine. > > As an aside, I have a hunch this isn't the reason YES and NO wound up in > Objective-C in the first place. To me, it seems like the authors of the > early runtimes needed a pre-stdbool way of talking about truthiness and > falsiness knowing that C++ was already using true and false, MacTypes was > already using TRUE and FALSE, and PascalCase identifiers were reserved for > class names. > >> On May 4, 2016, at 3:04 PM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I propose adding yes and no to the standard library as aliases for true and >> false Boolean values. When answering the questions posed by Boolean >> properties and methods, "yes" and "no" may provide better fits than "true" >> and "false". "Should this view be hidden?" "Yes!" "Does this collection >> contain the number 2?" "No!". Objective-C solved this by adding macro >> equivalents, admittedly with some attendant fuzziness because boolean >> implementation details allowed non 0/1 truth values. >> >> Swift on the other hand has very firm ideas about true and false. Adding yes >> and no literal aliases would enhance code readability with little cost. >> There's minimal historic support among languages for yes/no but Swift is an >> Apple-y kind of language and yes/no is an Apple-y kindness to developers. >> >> I performed a gmane search and did not find a previous thread on this >> subject. >> >> -- E >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution