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
> <[email protected]>:
>
> 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
>> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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
