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

[Jeremy Pereira]

> On 15 Dec 2015, at 22:17, Bruno Berisso via swift-evolution <swift-evolution at 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’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.