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

[Marc Knaup]

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 at 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 at 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 at 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 at 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 at 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 at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>> _______________________________________________
>> 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/9676e362/attachment.html>