[swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false
swift-evolution at haravikk.me
Wed May 4 17:08:09 CDT 2016
I’m a big fan of natural language style statements in code, but I think it would have to be a change of true/false or yes/no across the entire language, introducing lots of options creates uncertainty, especially for newer programmers. However I’m not sure if I’d want that, as true/false are the more appropriate options when you think of it in terms of logic statements, and they do still read to a reasonable degree as natural language, in fact when you think of it in terms of logic it evokes more of the sense that a statement is absolutely true or false, whereas yes or no, though still positive or negative, don’t quite have that same impact.
So I appreciate the intent behind this, but I think I agree with others that we don’t really want to add synonyms where there’s no clear advantage, and the possibility of confusion.
> On 4 May 2016, at 20:04, 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
More information about the swift-evolution