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


(Erica Sadun) #1

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


(Jordan Rose) #2

-1 from me. We should not introduce two equivalent spellings for the same thing.

(Yes, there are sometimes multiple ways to accomplish something, but they are not nearly this close.)

Jordan

···

On May 4, 2016, at 12:04, Erica Sadun via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Robert Widmann) #3

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jacob Bandes-Storch) #4

It's worth looking into CoffeeScript, in which true/false, yes/no, and
on/off are all accepted.

···

On Wed, May 4, 2016 at 12:04 PM Erica Sadun via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #5

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #6

I have seen wrong usage of bool values in Objective-C many times, and although most of those weren't real problems, I'd rather prefer to be forced to use a single pair of words for true/false.
If this single pair is true/false or yes/no (or even .yes/.no [enum]) isn't that important to me, so I'm less opposed to change the names instead of introducing an alias.


(David Owens II) #7

Agreed. -1.

···

Sent from my iPhone

On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

-1 from me. We should not introduce two equivalent spellings for the same thing.

(Yes, there are sometimes multiple ways to accomplish something, but they are not nearly this close.)

Jordan

On May 4, 2016, at 12:04, Erica Sadun via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #8

-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

···

On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

Jordan

On May 4, 2016, at 12:04, Erica Sadun via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Josh Parmenter) #9

I agree - please - just don’t. This is easy enough to create on your own if you wish, but I think it is easier for new developers to the language not to have to ask what differences there are between ‘true’ and ‘yes’ and ‘YES' … etc

···

On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

-1 from me. We should not introduce two equivalent spellings for the same thing.

(Yes, there are sometimes multiple ways to accomplish something, but they are not nearly this close.)

Jordan

On May 4, 2016, at 12:04, Erica Sadun via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@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@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Joshua Parmenter | Software Development

T 248 777 7777
C 206 437 1551
F 248 616 1980
www.vectorform.com<http://www.vectorform.com/>

Vectorform
2107 Elliott Ave Suite 303
Seattle, WA 98121 USA

Think Tank. Lab. Studio.
We invent digital products and experiences.

SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD


(Michael Peternell) #10

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Goffredo Marocchi) #11

I think the descriptive/natural language aspect of Objective-C and Cocoa was and is a strength that should be kept in Swift too.
It may be perceived as a pragmatist attempt to simplify the language somewhat or make it appear friendlier, but it is not a bad thing in and of itself.

[[iOS messageWithData:ideas] broadcast]

···

On 5 May 2016, at 08:54, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I have seen wrong usage of bool values in Objective-C many times, and although most of those weren't real problems, I'd rather prefer to be forced to use a single pair of words for true/false.
If this single pair is true/false or yes/no (or even .yes/.no [enum]) isn't that important to me, so I'm less opposed to change the names instead of introducing an alias.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jacopo Andrea Giola) #12

-1 for me as well.

One of the most FAQ of other fellow developers coming from other languages are often confuse by the YES/NO boolean in Obj-C and always asks why I use those and not true/false (and don’t get me started on nil/Nil/NULL).
I don’t want to find in the future discussion on StackOverflow with titles like “What are the differences between true/yes/on and false/no/off in Swift?” or “Is more correct to use yes or on in method x?”

Jacopo


(Adrian Zubarev) #13

-1 as well. Everything has already been said by the community. Swift should evolve on its own and don't care around old garbage. true and false is and was the best way to express a boolean.

···

--
Adrian Zubarev

Am 5. Mai 2016 um 11:56:55, Jacopo Andrea Giola via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

-1 for me as well.

One of the most FAQ of other fellow developers coming from other languages are often confuse by the YES/NO boolean in Obj-C and always asks why I use those and not true/false (and don’t get me started on nil/Nil/NULL).
I don’t want to find in the future discussion on StackOverflow with titles like “What are the differences between true/yes/on and false/no/off in Swift?” or “Is more correct to use yes or on in method x?”

Jacopo

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #14

Same, -1 from me. I’m not saying its a bad idea, just no worth polluting the standard library.

···

On 05 May 2016, at 06:06, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> 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 :slight_smile:

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 <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution