On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution <[email protected]> wrote: > -1 from me. We should not introduce two equivalent spellings for the same > thing.
I agree with Jordan in this case. I’m aware of the ObjC precedent, but keep in mind that that precedent was formed in the pre-ANSI-C days. IMO, it is better to have a single way to specify a concept, rather than two identical ways. Also, YAGNI :-) I agree that we haven’t had a thread on this concept though! -Chris > Jordan > > >> On May 4, 2016, at 12:04, 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
