Remove (!) logical negation operator

Evolution Discussion
1

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional values
it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to improve
the *!* to something more clear at a glance and that doesn't have different
behaviour depending where it appears in an expression.

Thanks,

2

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the
exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy to
miss and the negation was not or no longer intended.

···

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

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional
values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to improve
the *!* to something more clear at a glance and that doesn't have
different behaviour depending where it appears in an expression.

Thanks,

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

3

I do not see a problem with the '!' negation operator. The case with forced unwrap + negation doesn't happen very often, (in my opinion) doesn't look that bad, and certainly isn't confusing. The other example cases also look pretty clear to me. Usage of '!' for implicit unwrapping vs its usage for negation is well-separated (one being prefix, the other postfix).

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.

/T

···

Op 15 dec. 2015, om 15:11 heeft Bruno Berisso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> het volgende geschreven:

Hello,

I'm really used to negate logical expressions with this operator but it never feels confortable to me. If I need to negate some complex expression sometimes I prefer to write a temporal variable and then negate that with ! because I fear than others, or myself, could overlook it and cause confusion.

Now that Swift use the same operator to force the unwrap of optional values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a not operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if not is the right path here but I really want to improve the ! to something more clear at a glance and that doesn't have different behaviour depending where it appears in an expression.

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

4

My vote is to leave "!" as is. I'd support changing the "unwrap" operator
to something else.

Sprinkling "not" all over my source files seems noisy to me. Like
AppleScript, it sounds good in theory, but in practice the code is no
easier to read than before.

I find it kind of strange that the last couple years the internet suddenly
views C language features with great suspicion. I have no problem with any
of the C features that remain in Swift. I find far more confusing the
remaining features and conventions from Obj-C and Cocoa.

···

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

I do not see a problem with the '!' negation operator. The case with
forced unwrap + negation doesn't happen very often, (in my opinion) doesn't
look that bad, and certainly isn't confusing. The other example cases also
look pretty clear to me. Usage of '!' for implicit unwrapping vs its usage
for negation is well-separated (one being prefix, the other postfix).

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.

/T

Op 15 dec. 2015, om 15:11 heeft Bruno Berisso via swift-evolution < > swift-evolution@swift.org> het volgende geschreven:

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional
values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to improve
the *!* to something more clear at a glance and that doesn't have
different behaviour depending where it appears in an expression.

Thanks,
_______________________________________________
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

5

I'm interested to hear what the opinions are for this.
When I first read the idea I was a definite NO! (See what I did there :) )
But after thinking about it I'm interested to hear how people feel about this.
The obvious issue is what do we do with '!=' ?
Most languages which do not use ! for negation use '<>' for '!=' and I'm no sure how popular that would be.

ABR.

···

On 15 Dec 2015, at 15:01, Marc Knaup via swift-evolution <swift-evolution@swift.org> wrote:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy to miss and the negation was not or no longer intended.

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

I'm really used to negate logical expressions with this operator but it never feels confortable to me. If I need to negate some complex expression sometimes I prefer to write a temporal variable and then negate that with ! because I fear than others, or myself, could overlook it and cause confusion.

Now that Swift use the same operator to force the unwrap of optional values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a not operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if not is the right path here but I really want to improve the ! to something more clear at a glance and that doesn't have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

6

Andrew, we could theoretically implement `not`-negation and continue to use
!= until a better solution is found. Baby steps and all that.

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)`?

···

On Tue, Dec 15, 2015 at 10:19 AM Andrew Brown via swift-evolution < swift-evolution@swift.org> wrote:

I'm interested to hear what the opinions are for this.
When I first read the idea I was a definite NO! (See what I did there :) )
But after thinking about it I'm interested to hear how people feel about
this.
The obvious issue is what do we do with '!=' ?
Most languages which do not use ! for negation use '<>' for '!=' and I'm
no sure how popular that would be.

ABR.

On 15 Dec 2015, at 15:01, Marc Knaup via swift-evolution < > swift-evolution@swift.org> wrote:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the
exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy to
miss and the negation was not or no longer intended.

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

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional
values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to
improve the *!* to something more clear at a glance and that doesn't
have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

7

Good point!
The negating equality and identity operators != and !== both wouldn't fit
anymore.

···

On Tue, Dec 15, 2015 at 4:19 PM, Andrew Brown <a.br@me.com> wrote:

I'm interested to hear what the opinions are for this.
When I first read the idea I was a definite NO! (See what I did there :) )
But after thinking about it I'm interested to hear how people feel about
this.
The obvious issue is what do we do with '!=' ?
Most languages which do not use ! for negation use '<>' for '!=' and I'm
no sure how popular that would be.

ABR.

On 15 Dec 2015, at 15:01, Marc Knaup via swift-evolution < > swift-evolution@swift.org> wrote:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the
exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy to
miss and the negation was not or no longer intended.

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

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional
values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to
improve the *!* to something more clear at a glance and that doesn't
have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

8

I agree with that.

However, should `!` be removed, I'd suggest `~` — which already means
negation for integers, but is currently not defined on booleans.

···

On 12/15/15 14:05, Tommy van der Vorst 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.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."

9

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

···

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.

10

I never liked "!" because it can so easily be overlooked, so I'm fine with "not"

-Thorsten

···

Am 15.12.2015 um 16:01 schrieb Marc Knaup via swift-evolution <swift-evolution@swift.org>:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy to miss and the negation was not or no longer intended.

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

I'm really used to negate logical expressions with this operator but it never feels confortable to me. If I need to negate some complex expression sometimes I prefer to write a temporal variable and then negate that with ! because I fear than others, or myself, could overlook it and cause confusion.

Now that Swift use the same operator to force the unwrap of optional values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a not operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if not is the right path here but I really want to improve the ! to something more clear at a glance and that doesn't have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

11

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?

12

Your email did break out of the thread into its own one.
(at least in Google Mail)

···

On Tue, Dec 15, 2015 at 8:47 PM, Rainer Brockerhoff via swift-evolution < swift-evolution@swift.org> wrote:

On 12/15/15 14:05, Tommy van der Vorst 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 agree with that.

However, should `!` be removed, I'd suggest `~` — which already means
negation for integers, but is currently not defined on booleans.

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

+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

14

I'm a fan of wordy over cryptic operators. It's easier to the eyes.
However, the design of Swift seems to be unable to accept word as operator.
So, we have to accept cryptic operators.

I'm agree that as ! is used in optionals, it wouldn't fit to be used as
"not" anymore.

So, I vote for <> for "not equal". :)

Regards,

-Bee

···

On Tue, Dec 15, 2015 at 10:57 PM, Marc Knaup via swift-evolution < swift-evolution@swift.org> wrote:

Good point!
The negating equality and identity operators != and !== both wouldn't fit
anymore.

On Tue, Dec 15, 2015 at 4:19 PM, Andrew Brown <a.br@me.com> wrote:

I'm interested to hear what the opinions are for this.
When I first read the idea I was a definite NO! (See what I did there :) )
But after thinking about it I'm interested to hear how people feel about
this.
The obvious issue is what do we do with '!=' ?
Most languages which do not use ! for negation use '<>' for '!=' and I'm
no sure how popular that would be.

ABR.

On 15 Dec 2015, at 15:01, Marc Knaup via swift-evolution < >> swift-evolution@swift.org> wrote:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the
exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy
to miss and the negation was not or no longer intended.

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

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional
values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to
improve the *!* to something more clear at a glance and that doesn't
have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

15

There's always ≠ but then it's just a hop, skip, and a jump to APL.

-- E
p.s. I like != for inequality and ! for Boolean negation

···

On Dec 15, 2015, at 9:11 AM, Marc Knaup via swift-evolution <swift-evolution@swift.org> wrote:

What would be the replacement for "not identical" then?
<=> ?

<> is a bit weird and could potentially conflict/be confused with generics.

On Tue, Dec 15, 2015 at 5:09 PM, Bee <bee.ography@gmail.com <mailto:bee.ography@gmail.com>> wrote:
I'm a fan of wordy over cryptic operators. It's easier to the eyes. However, the design of Swift seems to be unable to accept word as operator. So, we have to accept cryptic operators.

I'm agree that as ! is used in optionals, it wouldn't fit to be used as "not" anymore.

So, I vote for <> for "not equal". :)

Regards,

-Bee

On Tue, Dec 15, 2015 at 10:57 PM, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Good point!
The negating equality and identity operators != and !== both wouldn't fit anymore.

On Tue, Dec 15, 2015 at 4:19 PM, Andrew Brown <a.br@me.com <mailto:a.br@me.com>> wrote:
I'm interested to hear what the opinions are for this.
When I first read the idea I was a definite NO! (See what I did there :) )
But after thinking about it I'm interested to hear how people feel about this.
The obvious issue is what do we do with '!=' ?
Most languages which do not use ! for negation use '<>' for '!=' and I'm no sure how popular that would be.

ABR.

On 15 Dec 2015, at 15:01, Marc Knaup via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy to miss and the negation was not or no longer intended.

On Tue, Dec 15, 2015 at 3:11 PM, Bruno Berisso via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello,

I'm really used to negate logical expressions with this operator but it never feels confortable to me. If I need to negate some complex expression sometimes I prefer to write a temporal variable and then negate that with ! because I fear than others, or myself, could overlook it and cause confusion.

Now that Swift use the same operator to force the unwrap of optional values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a not operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if not is the right path here but I really want to improve the ! to something more clear at a glance and that doesn't have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

16

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 <mailto:swift-evolution@swift.org>> wrote:

On 15 Dec 2015, at 17:05, Tommy van der Vorst via swift-evolution <swift-evolution@swift.org <mailto: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 <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

17

FWIW, this is not a likely direction for Swift, and has been discussed before:
https://lists.swift.org/pipermail/swift-evolution/2015-December/000032.html

-Chris

···

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.

18

What would be the replacement for "not identical" then?
<=> ?

<> is a bit weird and could potentially conflict/be confused with generics.

···

On Tue, Dec 15, 2015 at 5:09 PM, Bee <bee.ography@gmail.com> wrote:

I'm a fan of wordy over cryptic operators. It's easier to the eyes.
However, the design of Swift seems to be unable to accept word as operator.
So, we have to accept cryptic operators.

I'm agree that as ! is used in optionals, it wouldn't fit to be used as
"not" anymore.

So, I vote for <> for "not equal". :)

Regards,

-Bee

On Tue, Dec 15, 2015 at 10:57 PM, Marc Knaup via swift-evolution < > swift-evolution@swift.org> wrote:

Good point!
The negating equality and identity operators != and !== both wouldn't fit
anymore.

On Tue, Dec 15, 2015 at 4:19 PM, Andrew Brown <a.br@me.com> wrote:

I'm interested to hear what the opinions are for this.
When I first read the idea I was a definite NO! (See what I did there :)
)
But after thinking about it I'm interested to hear how people feel about
this.
The obvious issue is what do we do with '!=' ?
Most languages which do not use ! for negation use '<>' for '!=' and I'm
no sure how popular that would be.

ABR.

On 15 Dec 2015, at 15:01, Marc Knaup via swift-evolution < >>> swift-evolution@swift.org> wrote:

I'm uncertain but it's definitely worth considering.

I also think that it's weird at the moment since in most cases the
exclamation mark is now something dangerous.
I also had a couple of bugs in my code because the operator is too easy
to miss and the negation was not or no longer intended.

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

Hello,

I'm really used to negate logical expressions with this operator but it
never feels confortable to me. If I need to negate some complex expression
sometimes I prefer to write a temporal variable and then negate that with
*!* because I fear than others, or myself, could overlook it and cause
confusion.

Now that Swift use the same operator to force the unwrap of optional
values it becomes even worse.

Consider this examples:

if someOptionalValue != nil {
    ...
    if !(otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

Or even worse, what happen when negating Optional<Bool> values?

//Best case
if let value = optionalBool where !value {
    ...
}

//Worse case
if !optionalBool! {
    ...
}

Now what happen with this examples if we instead use a *not* operator:

if someOptionalValue != nil {
    ...
    if not (otherBoolValue && someOptionalValue! > 0) {
        ...
    }
}

if let value = optionalBool where not value {
    ...
}

if not optionalBool! {
    ...
}

I'm not sure if *not* is the right path here but I really want to
improve the *!* to something more clear at a glance and that doesn't
have different behaviour depending where it appears in an expression.

Thanks,

_______________________________________________
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

19

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

20

I subscribe to the list in digest form, but tried to use "Undigestify"
(on Thunderbird) to hopefully preserve threading. Apparently it threads
to the digest, instead of to the digested threads. :-(

BTW, +1 on continuing to use Mailman, despite the threading issue. Not
everybody has broadband all the time, and I prefer to have messages
stored locally.

···

On 12/15/15 18:02, Marc Knaup wrote:

Your email did break out of the thread into its own one.
(at least in Google Mail)

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."