Remove (!) logical negation operator

[Bruno_Berisso]

Keep in mind that the discussion isn't "!" vs "not" but how to address
basically two issues with "!":
- invisibility in non-trivial expressions
- collision with the forced unwrapped of optional values

I personally collect really good arguments against the use of "not" as an
alternative to address this two issues without being to disruptive.

I think that the best option we have until now is "~" used for bitwise
"not" operation. This bring the next question: why we need to distinguish
between bitwise logical operators and boolean logical ones? Doesn't that
should be implicit in the type of the operands?

The bitwise operators are not defined for Bool types and logical operations
are only defined for Booleans. So we could have:

boolValueX & boolValueY = Boolean "and"
notBoolX & notBoolY = bitwise "and"
~boolValueX = Boolean "not"
~notBoolX = bitwise "not"

I'm thinking out loud here so let me know if this doesn't make sense.

···

On Tue, Dec 15, 2015 at 17:33 Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:

Today &&, ||, (prefix) !, !=, and !== are not magic; they are just like
every other operator. Adding user-overridable keyword operators would be a
non-trivial change to the language.

(Everyone—nearly—keeps forgetting about != and !==. Replacing these with
not(a == b) is not really a good answer.)

Jordan

On Dec 15, 2015, at 12:13 , Rudolf Adamkovic via swift-evolution < > swift-evolution@swift.org> wrote:

+1 for clean-up:

• "and" instead of &&
• "or" instead of ||
• "not" instead of !
• if expressions instead of ?!

Easier to read, easier to type, easier to understand for beginners.

As a bonus, it doesn't look like optionals (less !s and ?s).

R+

Sent from my iPhone

On 15 Dec 2015, at 20:49, Sune Foldager via swift-evolution < > swift-evolution@swift.org> wrote:

On 15 Dec 2015, at 17:05, Tommy van der Vorst via swift-evolution < > swift-evolution@swift.org> wrote:

I *do* see negative effects of removing it: ! is part of virtually all
programming languages currently in use, any decent programmer is accustomed
to it and read it like 'not' in their head anyway. Removing would
definitely confuse newcomers to the language.

I completely agree. While it *is* a bit weird to use the same symbol for
forced unwrap and its more traditional use as boolean negation, removing
the one virtually all other languages have is not the answer. If we do
that, why not also ~ for binary negation, || and && and even + and -.

It’s always a balance between verbosity, “natural language”-ness and
terseness. It’s not always easier to read code that’s very verbose, and I’m
sure we don’t want Swift to be like AppleScript.

-Sune

_______________________________________________
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

[cryo (Sune Foldager)]

+1 for clean-up:

• "and" instead of &&
• "or" instead of ||
• "not" instead of !
• if expressions instead of ?!

What you call clean up I would call making needlessly verbose. By the same argument, why not “plus” and “minus”?

Easier to read, easier to type, easier to understand for beginners.

Symbols are great because they stand out from text, and your variables and class members will be text. There is a reason mathematics uses a lot of symbols as well: It makes it easier to read. There is a learning curve, sure, but the same is the case with text: “and” is that logical or binary and? With symbols, one is && and the other is &.

As a bonus, it doesn't look like optionals (less !s and ?s).

No, instead it looks like AppleScript :( Catering to beginners is all good, but catering to experienced developers is ultimately more important, I think.

-Sune

···

On 15 Dec 2015, at 21:13, Rudolf Adamkovic <salutis@me.com> wrote:

[Al_Skipp]

There’s always /= and /== (not a serious suggestion, but it could work : )

···

On 15 Dec 2015, at 20:33, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

Today &&, ||, (prefix) !, !=, and !== are not magic; they are just like every other operator. Adding user-overridable keyword operators would be a non-trivial change to the language.

(Everyone—nearly—keeps forgetting about != and !==. Replacing these with not(a == b) is not really a good answer.)

Jordan

[salutis (Rudolf Adamkovič)]

Ah, haven't see that one. Very interesting!

···

Sent from my iPhone

On 15 Dec 2015, at 22:41, Chris Lattner <clattner@apple.com> wrote:

On Dec 15, 2015, at 12:13 PM, Rudolf Adamkovic via swift-evolution <swift-evolution@swift.org> wrote:

+1 for clean-up:

• "and" instead of &&
• "or" instead of ||
• "not" instead of !
• if expressions instead of ?!

Easier to read, easier to type, easier to understand for beginners.

FWIW, this is not a likely direction for Swift, and has been discussed before:
[swift-evolution] Change the name of the boolean operators?

-Chris

[Andrey_Tarantsov]

I also hit the != vs <> dilema and conclude that we could continue using the != as "not equal".

While I agree with this, I want to point out that there's a precedent of /= in Ada. It makes the most sense, if you think about it, because that's how ≠ looks like.

A.

[Andrey_Tarantsov]

+1 for clean-up:

• "and" instead of &&
• "or" instead of ||
• "not" instead of !
• if expressions instead of ?!

+1 from me as well. Should be a separate proposal, though?

I understand the concern that Chris expressed before:

We’ve briefly considered this in the past. However, this doesn’t align well with the design of swift, which partitions infix and prefix operators into their own namespace (composed of operator characters) and normal identifiers (composed of “identifier characters”). You can see the grammar for this in the Swift Programming Language Reference.

...but I don't see why the language cannot be extended to allow defining and using identifiers as operators.

A.

[Austin (Austin Zheng)]

-1. In terms of C features that people complain about, prefix '!' for
negation doesn't seem to be high on the list, and it's never something that
has caused me or any other developer I know a problem (although these are
all anecdotes, take them as you will). A linter/style checker can always be
used if you really want to enforce 'x == false' over '!x' for your team or
project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am
strongly against the former and for the latter. The symbols are 'cryptic'
for the few minutes it takes to figure out what they mean, after which the
developer is good for a lifetime of coding in many different languages. The
words are nicely self-descriptive for a bit, then increase verbosity and
destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

···

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution < swift-evolution@swift.org> wrote:

> For example in `if let aBool = aBool where !aBool`, let's suppose that
we know that `aBool` optional it's not empty before this check. How would
you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators
I'm agnostic on what's best but imho we need to have consistency. E.g.
either all words, or all math symbols or all the same as in C (current
state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced
unwrapping is undesirable anyway so the confusion can be minimized in
practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution < > swift-evolution@swift.org> wrote:

I also hit the *!=* vs *<>* dilema and conclude that we could continue
using the *!=* as "not equal".

It's true that it will not be as consistent as before but I think it's a
reasonable price to pay taking into account the issues with *!* as
'not'.

Not that I necessarily think this proposal is a good idea. The given
examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue =
someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol
depending only in where it appears in an expression. Adding that *!*
character is really easy to miss in an expression make it at last
uncomfortable.

I agree that we are all really used to find *!* in logical expressions
and our brain is trained to translate it to NOT automatically but that
doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that we
know that `aBool` optional it's not empty before this check. How would you
write it? `!aBool!` or with the `if let...` ?

I think that clearly *!* is not good choice for negation but my mind is
so used to it that I can't totally affirm that *not* is *the* alternative
to it. Do we have another alternatives?

_______________________________________________
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

[Bruno_Berisso]

> For example in `if let aBool = aBool where !aBool`, let's suppose that
we know that `aBool` optional it's not empty before this check. How would
you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

I think it will be `if aBool! == false {} ` to match the case in my
previous example (not the *!*) (and note that I need to note the *!* :) )

I have the feeling that the Swift dev team had to follow this path when
they choose to use *!* to unwrap the optional values, it will be great to
have they insight.

As for the whole topic of words vs cryptic symbols for Boolean operators

I'm agnostic on what's best but imho we need to have consistency. E.g.
either all words, or all math symbols or all the same as in C (current
state of things).

Agree. We could / should then use the ~ ?

[fluidsonic (Marc Knaup)]

~ is just trading one operator for another, which isn't a lot better.
Also ~ is quire annoying to type on non-english keyboards.

"&" and "|" have a different meaning than "&&" and "||".
The former two evaluate both operands and then perform the logical
operation on the results.
The latter two evaluate the right operand iff the left operand is true or
false respectively.

···

On Tue, Dec 15, 2015 at 10:17 PM, Bruno Berisso via swift-evolution < swift-evolution@swift.org> wrote:

Keep in mind that the discussion isn't "!" vs "not" but how to address
basically two issues with "!":
- invisibility in non-trivial expressions
- collision with the forced unwrapped of optional values

I personally collect really good arguments against the use of "not" as an
alternative to address this two issues without being to disruptive.

I think that the best option we have until now is "~" used for bitwise
"not" operation. This bring the next question: why we need to distinguish
between bitwise logical operators and boolean logical ones? Doesn't that
should be implicit in the type of the operands?

The bitwise operators are not defined for Bool types and logical
operations are only defined for Booleans. So we could have:

boolValueX & boolValueY = Boolean "and"
notBoolX & notBoolY = bitwise "and"
~boolValueX = Boolean "not"
~notBoolX = bitwise "not"

I'm thinking out loud here so let me know if this doesn't make sense.

On Tue, Dec 15, 2015 at 17:33 Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:

Today &&, ||, (prefix) !, !=, and !== are not magic; they are just like
every other operator. Adding user-overridable keyword operators would be a
non-trivial change to the language.

(Everyone—nearly—keeps forgetting about != and !==. Replacing these with
not(a == b) is not really a good answer.)

Jordan

On Dec 15, 2015, at 12:13 , Rudolf Adamkovic via swift-evolution < >> swift-evolution@swift.org> wrote:

+1 for clean-up:

• "and" instead of &&
• "or" instead of ||
• "not" instead of !
• if expressions instead of ?!

Easier to read, easier to type, easier to understand for beginners.

As a bonus, it doesn't look like optionals (less !s and ?s).

R+

Sent from my iPhone

On 15 Dec 2015, at 20:49, Sune Foldager via swift-evolution < >> swift-evolution@swift.org> wrote:

On 15 Dec 2015, at 17:05, Tommy van der Vorst via swift-evolution < >> swift-evolution@swift.org> wrote:

I *do* see negative effects of removing it: ! is part of virtually all
programming languages currently in use, any decent programmer is accustomed
to it and read it like 'not' in their head anyway. Removing would
definitely confuse newcomers to the language.

I completely agree. While it *is* a bit weird to use the same symbol for
forced unwrap and its more traditional use as boolean negation, removing
the one virtually all other languages have is not the answer. If we do
that, why not also ~ for binary negation, || and && and even + and -.

It’s always a balance between verbosity, “natural language”-ness and
terseness. It’s not always easier to read code that’s very verbose, and I’m
sure we don’t want Swift to be like AppleScript.

-Sune

_______________________________________________
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

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

[Craig_Cruden]

-1 as well.

I cannot think of a language where I don’t have ! as negate (which I read as not).

What would it be replaced by a keyword of “not”?

···

On 2015-12-16, at 1:18:14, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

-1. In terms of C features that people complain about, prefix '!' for negation doesn't seem to be high on the list, and it's never something that has caused me or any other developer I know a problem (although these are all anecdotes, take them as you will). A linter/style checker can always be used if you really want to enforce 'x == false' over '!x' for your team or project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am strongly against the former and for the latter. The symbols are 'cryptic' for the few minutes it takes to figure out what they mean, after which the developer is good for a lifetime of coding in many different languages. The words are nicely self-descriptive for a bit, then increase verbosity and destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators I'm agnostic on what's best but imho we need to have consistency. E.g. either all words, or all math symbols or all the same as in C (current state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced unwrapping is undesirable anyway so the confusion can be minimized in practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I also hit the != vs <> dilema and conclude that we could continue using the != as "not equal".

It's true that it will not be as consistent as before but I think it's a reasonable price to pay taking into account the issues with ! as 'not'.

Not that I necessarily think this proposal is a good idea. The given examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue = someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol depending only in where it appears in an expression. Adding that !character is really easy to miss in an expression make it at last uncomfortable.

I agree that we are all really used to find ! in logical expressions and our brain is trained to translate it to NOT automatically but that doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

I think that clearly ! is not good choice for negation but my mind is so used to it that I can't totally affirm that not is the alternative to it. Do we have another alternatives?

_______________________________________________
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

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

[jeremyp (Jeremy Pereira)]

Keep in mind that the discussion isn't "!" vs "not" but how to address basically two issues with "!":
- invisibility in non-trivial expressions
- collision with the forced unwrapped of optional values

I’ve coded with C and C like languages for more years than I like to admit and this thread is the first time I’ve ever heard that there is a problem with the visibility of the ! operator.

I also am quite surprised that the overloading of the meaning of symbols is a serious issue. It’s natural for people to distinguish the meaning of things by context. C programmers don’t complain that they are always confusing pointer dereferencing with multiplication do they? No.

I am -1 for replacing a perfectly adequate symbol with a word, because it is much harder to distinguish operators that are words from the identifiers they operate on (for this reason I am against replacing ?: with if then else too).

Having said all that...

I think that the best option we have until now is "~" used for bitwise "not" operation. This bring the next question: why we need to distinguish between bitwise logical operators and boolean logical ones? Doesn't that should be implicit in the type of the operands?

I think this is a fantastic idea. Given that there is a first class boolean type in Swift and we no longer have to pretend that ints are bools, there is no reason not to use ~ for logical negation of both types. The ! and && and || operators only exist at all because C uses the same type for both bools and small arrays of bits.

The bitwise operators are not defined for Bool types and logical operations are only defined for Booleans. So we could have:

boolValueX & boolValueY = Boolean "and"
notBoolX & notBoolY = bitwise "and"
~boolValueX = Boolean "not"
~notBoolX = bitwise “not"

I'm thinking out loud here so let me know if this doesn't make sense.

The only problem with this is what it does to existing code. I think you would have to introduce them in parallel with the old p=operators and a deprecation warning.

···

On 15 Dec 2015, at 22:17, Bruno Berisso via swift-evolution <swift-evolution@swift.org> wrote:

[Bruno_Berisso]

I think that my original proposal was clearly discarded (twenty mails ago)
so to preserve order please consider open other threads to continue the
discussions started here.

I really enjoyed sharing thoughts with you guys :) Thanks to everyone for
participate.

···

On Thu, Dec 17, 2015 at 08:29 Andrey Tarantsov via swift-evolution < swift-evolution@swift.org> wrote:

+1 for clean-up:

• "and" instead of &&
• "or" instead of ||
• "not" instead of !
• if expressions instead of ?!

+1 from me as well. Should be a separate proposal, though?

I understand the concern that Chris expressed before:

> We’ve briefly considered this in the past. However, this doesn’t align
well with the design of swift, which partitions infix and prefix operators
into their own namespace (composed of operator characters) and normal
identifiers (composed of “identifier characters”). You can see the grammar
for this in the Swift Programming Language Reference.

...but I don't see why the language cannot be extended to allow defining
and using identifiers as operators.

A.

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

[possen (Paul Ossenbruggen)]

Why stop at not? How about? “and or xor. I think C++ allows this optionally

if someOptionalValue != nil {
    ...
    if not (otherBoolValue and someOptionalValue! > 0) {
        ...
    }
}
if otherBoolValue and someOptionalValue or yetAnotherOptionalValue {
  if otherBoolValue xor yetAnotherOptionalValue {
  }
}

···

On Dec 15, 2015, at 10:51 AM, Stephen Canon via swift-evolution <swift-evolution@swift.org> wrote:

Personally I really don’t mind ! for negation, but if it were to be removed the natural replacement would be ~. Boolean negation *is* bitwise negation, after all. != would be spelled ~= a la Lua and MATLAB.

– Steve

On Dec 15, 2015, at 1:45 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Though the “! means negation” operators are too widely used and too elegant for me to get behind this change, I would say a word in favor of Swift’s loose convention of “! means danger:”

  ! (force unwrap)
  ! (IUO)
  as!
  try!

…all mean “potential crash here.” That’s a nice convention.

However, because not all potential crash points are marked with ! (array subscripting, assert / precondition / fatalError, and of course any function that contains one of the above crashing constructs), we can’t say “danger implies !”. It thus doesn’t seem worth the pain of removing the !, != and !== operators to make the “! implies danger” association strong.

Still, I’d be in favor of anything that helps me audit code for potential crash points — if not changing the negation operators, then perhaps something AST based, perhaps even library annotations. At the very least, I’d appreciate it if SourceKit / Xcode could apply different syntax coloring to the negation bang and the danger bang.

Cheers,

Paul

On Dec 15, 2015, at 12:26 PM, Craig Cruden via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1 as well.

I cannot think of a language where I don’t have ! as negate (which I read as not).

What would it be replaced by a keyword of “not”?

On 2015-12-16, at 1:18:14, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1. In terms of C features that people complain about, prefix '!' for negation doesn't seem to be high on the list, and it's never something that has caused me or any other developer I know a problem (although these are all anecdotes, take them as you will). A linter/style checker can always be used if you really want to enforce 'x == false' over '!x' for your team or project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am strongly against the former and for the latter. The symbols are 'cryptic' for the few minutes it takes to figure out what they mean, after which the developer is good for a lifetime of coding in many different languages. The words are nicely self-descriptive for a bit, then increase verbosity and destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators I'm agnostic on what's best but imho we need to have consistency. E.g. either all words, or all math symbols or all the same as in C (current state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced unwrapping is undesirable anyway so the confusion can be minimized in practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I also hit the != vs <> dilema and conclude that we could continue using the != as "not equal".

It's true that it will not be as consistent as before but I think it's a reasonable price to pay taking into account the issues with ! as 'not'.

Not that I necessarily think this proposal is a good idea. The given examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue = someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol depending only in where it appears in an expression. Adding that !character is really easy to miss in an expression make it at last uncomfortable.

I agree that we are all really used to find ! in logical expressions and our brain is trained to translate it to NOT automatically but that doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

I think that clearly ! is not good choice for negation but my mind is so used to it that I can't totally affirm that not is the alternative to it. Do we have another alternatives?

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

[Paul_Cantrell]

Though the “! means negation” operators are too widely used and too elegant for me to get behind this change, I would say a word in favor of Swift’s loose convention of “! means danger:”

  ! (force unwrap)
  ! (IUO)
  as!
  try!

…all mean “potential crash here.” That’s a nice convention.

However, because not all potential crash points are marked with ! (array subscripting, assert / precondition / fatalError, and of course any function that contains one of the above crashing constructs), we can’t say “danger implies !”. It thus doesn’t seem worth the pain of removing the !, != and !== operators to make the “! implies danger” association strong.

Still, I’d be in favor of anything that helps me audit code for potential crash points — if not changing the negation operators, then perhaps something AST based, perhaps even library annotations. At the very least, I’d appreciate it if SourceKit / Xcode could apply different syntax coloring to the negation bang and the danger bang.

Cheers,

Paul

···

On Dec 15, 2015, at 12:26 PM, Craig Cruden via swift-evolution <swift-evolution@swift.org> wrote:

-1 as well.

I cannot think of a language where I don’t have ! as negate (which I read as not).

What would it be replaced by a keyword of “not”?

On 2015-12-16, at 1:18:14, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1. In terms of C features that people complain about, prefix '!' for negation doesn't seem to be high on the list, and it's never something that has caused me or any other developer I know a problem (although these are all anecdotes, take them as you will). A linter/style checker can always be used if you really want to enforce 'x == false' over '!x' for your team or project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am strongly against the former and for the latter. The symbols are 'cryptic' for the few minutes it takes to figure out what they mean, after which the developer is good for a lifetime of coding in many different languages. The words are nicely self-descriptive for a bit, then increase verbosity and destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators I'm agnostic on what's best but imho we need to have consistency. E.g. either all words, or all math symbols or all the same as in C (current state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced unwrapping is undesirable anyway so the confusion can be minimized in practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I also hit the != vs <> dilema and conclude that we could continue using the != as "not equal".

It's true that it will not be as consistent as before but I think it's a reasonable price to pay taking into account the issues with ! as 'not'.

Not that I necessarily think this proposal is a good idea. The given examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue = someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol depending only in where it appears in an expression. Adding that !character is really easy to miss in an expression make it at last uncomfortable.

I agree that we are all really used to find ! in logical expressions and our brain is trained to translate it to NOT automatically but that doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

I think that clearly ! is not good choice for negation but my mind is so used to it that I can't totally affirm that not is the alternative to it. Do we have another alternatives?

_______________________________________________
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

_______________________________________________
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

[BigZaphod (Sean Heber)]

This has come up before:

https://lists.swift.org/pipermail/swift-evolution/2015-December/000032.html

l8r
Sean

···

On Dec 15, 2015, at 12:59 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

Why stop at not? How about? “and or xor. I think C++ allows this optionally

if someOptionalValue != nil {
    ...
    if not (otherBoolValue and someOptionalValue! > 0) {
        ...
    }
}
if otherBoolValue and someOptionalValue or yetAnotherOptionalValue {
  if otherBoolValue xor yetAnotherOptionalValue {
  }
}

On Dec 15, 2015, at 10:51 AM, Stephen Canon via swift-evolution <swift-evolution@swift.org> wrote:

Personally I really don’t mind ! for negation, but if it were to be removed the natural replacement would be ~. Boolean negation *is* bitwise negation, after all. != would be spelled ~= a la Lua and MATLAB.

– Steve

On Dec 15, 2015, at 1:45 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

Though the “! means negation” operators are too widely used and too elegant for me to get behind this change, I would say a word in favor of Swift’s loose convention of “! means danger:”

  ! (force unwrap)
  ! (IUO)
  as!
  try!

…all mean “potential crash here.” That’s a nice convention.

However, because not all potential crash points are marked with ! (array subscripting, assert / precondition / fatalError, and of course any function that contains one of the above crashing constructs), we can’t say “danger implies !”. It thus doesn’t seem worth the pain of removing the !, != and !== operators to make the “! implies danger” association strong.

Still, I’d be in favor of anything that helps me audit code for potential crash points — if not changing the negation operators, then perhaps something AST based, perhaps even library annotations. At the very least, I’d appreciate it if SourceKit / Xcode could apply different syntax coloring to the negation bang and the danger bang.

Cheers,

Paul

On Dec 15, 2015, at 12:26 PM, Craig Cruden via swift-evolution <swift-evolution@swift.org> wrote:

-1 as well.

I cannot think of a language where I don’t have ! as negate (which I read as not).

What would it be replaced by a keyword of “not”?

On 2015-12-16, at 1:18:14, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

-1. In terms of C features that people complain about, prefix '!' for negation doesn't seem to be high on the list, and it's never something that has caused me or any other developer I know a problem (although these are all anecdotes, take them as you will). A linter/style checker can always be used if you really want to enforce 'x == false' over '!x' for your team or project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am strongly against the former and for the latter. The symbols are 'cryptic' for the few minutes it takes to figure out what they mean, after which the developer is good for a lifetime of coding in many different languages. The words are nicely self-descriptive for a bit, then increase verbosity and destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution <swift-evolution@swift.org> wrote:
> For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators I'm agnostic on what's best but imho we need to have consistency. E.g. either all words, or all math symbols or all the same as in C (current state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced unwrapping is undesirable anyway so the confusion can be minimized in practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution <swift-evolution@swift.org> wrote:
I also hit the != vs <> dilema and conclude that we could continue using the != as "not equal".

It's true that it will not be as consistent as before but I think it's a reasonable price to pay taking into account the issues with ! as 'not'.

Not that I necessarily think this proposal is a good idea. The given examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue = someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol depending only in where it appears in an expression. Adding that !character is really easy to miss in an expression make it at last uncomfortable.

I agree that we are all really used to find ! in logical expressions and our brain is trained to translate it to NOT automatically but that doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

I think that clearly ! is not good choice for negation but my mind is so used to it that I can't totally affirm that not is the alternative to it. Do we have another alternatives?

_______________________________________________
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

_______________________________________________
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

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

[Stephen_Canon]

Personally I really don’t mind ! for negation, but if it were to be removed the natural replacement would be ~. Boolean negation *is* bitwise negation, after all. != would be spelled ~= a la Lua and MATLAB.

– Steve

···

On Dec 15, 2015, at 1:45 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

Though the “! means negation” operators are too widely used and too elegant for me to get behind this change, I would say a word in favor of Swift’s loose convention of “! means danger:”

  ! (force unwrap)
  ! (IUO)
  as!
  try!

…all mean “potential crash here.” That’s a nice convention.

However, because not all potential crash points are marked with ! (array subscripting, assert / precondition / fatalError, and of course any function that contains one of the above crashing constructs), we can’t say “danger implies !”. It thus doesn’t seem worth the pain of removing the !, != and !== operators to make the “! implies danger” association strong.

Still, I’d be in favor of anything that helps me audit code for potential crash points — if not changing the negation operators, then perhaps something AST based, perhaps even library annotations. At the very least, I’d appreciate it if SourceKit / Xcode could apply different syntax coloring to the negation bang and the danger bang.

Cheers,

Paul

On Dec 15, 2015, at 12:26 PM, Craig Cruden via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1 as well.

I cannot think of a language where I don’t have ! as negate (which I read as not).

What would it be replaced by a keyword of “not”?

On 2015-12-16, at 1:18:14, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1. In terms of C features that people complain about, prefix '!' for negation doesn't seem to be high on the list, and it's never something that has caused me or any other developer I know a problem (although these are all anecdotes, take them as you will). A linter/style checker can always be used if you really want to enforce 'x == false' over '!x' for your team or project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am strongly against the former and for the latter. The symbols are 'cryptic' for the few minutes it takes to figure out what they mean, after which the developer is good for a lifetime of coding in many different languages. The words are nicely self-descriptive for a bit, then increase verbosity and destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators I'm agnostic on what's best but imho we need to have consistency. E.g. either all words, or all math symbols or all the same as in C (current state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced unwrapping is undesirable anyway so the confusion can be minimized in practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I also hit the != vs <> dilema and conclude that we could continue using the != as "not equal".

It's true that it will not be as consistent as before but I think it's a reasonable price to pay taking into account the issues with ! as 'not'.

Not that I necessarily think this proposal is a good idea. The given examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue = someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol depending only in where it appears in an expression. Adding that !character is really easy to miss in an expression make it at last uncomfortable.

I agree that we are all really used to find ! in logical expressions and our brain is trained to translate it to NOT automatically but that doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

I think that clearly ! is not good choice for negation but my mind is so used to it that I can't totally affirm that not is the alternative to it. Do we have another alternatives?

_______________________________________________
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

_______________________________________________
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

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

[Al_Skipp]

Don’t forget it’s perfectly fine to compare an Optional to a non-optional value with ==, the ! isn’t required and is potentially explosive.

···

On 15 Dec 2015, at 18:14, Bruno Berisso via swift-evolution <swift-evolution@swift.org> wrote:

> For example in `if let aBool = aBool where !aBool`, let's suppose that we know that `aBool` optional it's not empty before this check. How would you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

I think it will be `if aBool! == false {} ` to match the case in my previous example (not the !) (and note that I need to note the ! :) )

[Al_Skipp]

I cannot think of a language where I don’t have ! as negate (which I read as not).

There’s Haskell, a language well endowed with cryptic operators, but not prefix !, it uses a ‘not’ function instead.

You could do the same in Swift, should you wish:

func not(bool: Bool) -> Bool { return !bool }

And because in Swift, ‘if’ doesn’t require braces around the predicate, it doesn’t look too bad.
if not(x) { …

[fluidsonic (Marc Knaup)]

Lua is also quite popular and doesn't support the "!" operator but the
"not" keyword instead.
Adapting to that wasn't all that difficult for me when writing Lua for a
while. You rarely have to think about what a negation looks like because
"not" just comes to mind naturally. It's like you're writing regular text
in that moment.

In any case such a decision should not depend primarily on whether a
specific operator or keyword is common in other languages but whether it
helps expressing and understanding the code's intent. "not" achieves that,
esp. for newbies and people getting someone else's code.

···

On Tue, Dec 15, 2015 at 7:45 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote:

Though the “! means negation” operators are too widely used and too
elegant for me to get behind this change, I would say a word in favor of
Swift’s loose convention of “! means danger:”

! (force unwrap)
! (IUO)
as!
try!

…all mean “potential crash here.” That’s a nice convention.

However, because not all potential crash points are marked with ! (array
subscripting, assert / precondition / fatalError, and of course any
function that contains one of the above crashing constructs), we can’t say
“danger implies !”. It thus doesn’t seem worth the pain of removing the !,
!= and !== operators to make the “! implies danger” association strong.

Still, I’d be in favor of anything that helps me audit code for potential
crash points — if not changing the negation operators, then perhaps
something AST based, perhaps even library annotations. At the very least,
I’d appreciate it if SourceKit / Xcode could apply different syntax
coloring to the negation bang and the danger bang.

Cheers,

Paul

On Dec 15, 2015, at 12:26 PM, Craig Cruden via swift-evolution < > swift-evolution@swift.org> wrote:

-1 as well.

I cannot think of a language where I don’t have ! as negate (which I read
as not).

What would it be replaced by a keyword of “not”?

On 2015-12-16, at 1:18:14, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote:

-1. In terms of C features that people complain about, prefix '!' for
negation doesn't seem to be high on the list, and it's never something that
has caused me or any other developer I know a problem (although these are
all anecdotes, take them as you will). A linter/style checker can always be
used if you really want to enforce 'x == false' over '!x' for your team or
project.

'~' is already used for bitwise negation.

More broadly, in terms of "words" vs "cryptic symbols" as operators, I am
strongly against the former and for the latter. The symbols are 'cryptic'
for the few minutes it takes to figure out what they mean, after which the
developer is good for a lifetime of coding in many different languages. The
words are nicely self-descriptive for a bit, then increase verbosity and
destroy your ability to visually delineate arguments via symbols forever.

Best,
Austin

On Tue, Dec 15, 2015 at 9:59 AM, ilya via swift-evolution < > swift-evolution@swift.org> wrote:

> For example in `if let aBool = aBool where !aBool`, let's suppose that
we know that `aBool` optional it's not empty before this check. How would
you write it? `!aBool!` or with the `if let...` ?

if aBool == false {} covers this nicely.

As for the whole topic of words vs cryptic symbols for Boolean operators
I'm agnostic on what's best but imho we need to have consistency. E.g.
either all words, or all math symbols or all the same as in C (current
state of things).

You can always rewrite !x as (x==false) if x is a Bool and forced
unwrapping is undesirable anyway so the confusion can be minimized in
practice.

Ilya.

On Tue, Dec 15, 2015 at 19:56 Bruno Berisso via swift-evolution < >> swift-evolution@swift.org> wrote:

I also hit the *!=* vs *<>* dilema and conclude that we could continue
using the *!=* as "not equal".

It's true that it will not be as consistent as before but I think it's a
reasonable price to pay taking into account the issues with *!* as
'not'.

Not that I necessarily think this proposal is a good idea. The given
examples reek of being against unwrapping for some reason.

Why not use `if let aBool = aBool where !aBool`? And `if let someValue
= someValue where !(otherBoolValue && someValue > 0)`?

I think the issue is the complete different meanings of a symbol
depending only in where it appears in an expression. Adding that *!*character
is really easy to miss in an expression make it at last uncomfortable.

I agree that we are all really used to find *!* in logical expressions
and our brain is trained to translate it to NOT automatically but that
doesn't mean that it's good idea to keep it there.

For example in `if let aBool = aBool where !aBool`, let's suppose that
we know that `aBool` optional it's not empty before this check. How would
you write it? `!aBool!` or with the `if let...` ?

I think that clearly *!* is not good choice for negation but my mind is
so used to it that I can't totally affirm that *not* is *the* alternative
to it. Do we have another alternatives?

_______________________________________________
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

_______________________________________________
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

[trs (Thorsten Seitz)]

It just occurred to me that there is one problem with replacing "!" with "not":
"not" would be the first operator being a word, which would lead down a slippery slope that I'd rather not tread: would we allow user defined unary operators being words?
I'd rather not as this makes expressions unreadable IMHO. That is a problem I have with Scala: there they often use words as operators which I find difficult to read.
Haskell does not have this problem as "not" is just a unary function there.

So, I'd like to keep the ! even though I'm no friend of it.

-Thorsten

···

Am 15.12.2015 um 19:39 schrieb Al Skipp via swift-evolution <swift-evolution@swift.org>:

I cannot think of a language where I don’t have ! as negate (which I read as not).

There’s Haskell, a language well endowed with cryptic operators, but not prefix !, it uses a ‘not’ function instead.

You could do the same in Swift, should you wish:

func not(bool: Bool) -> Bool { return !bool }

And because in Swift, ‘if’ doesn’t require braces around the predicate, it doesn’t look too bad.
if not(x) { …

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