[swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

[Michael Peternell]

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 at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution