[swift-evolution] Remove (!) logical negation operator

[ilya]

> 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/b3a0074a/attachment.html>