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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
