If there is a proposal for this, I think it needs to be complete - i.e. adding:

var isFalse: Bool
var isTrue: Bool
var negatedValue: Self (on BooleanType)
var negatedBoolValue: Bool

In such terms, the BooleanType would be complete as you'd be able to express 
all boolean operations using functions/properties. The question is where would 
it be used. I do not think adding a negating variable at the end of several 
transformations is a good idea, perhaps something like this could be used in 
predicate programming...

> On May 22, 2016, at 9:30 AM, T.J. Usiyan via swift-evolution 
> <[email protected]> wrote:
> 
> `var isFalse: Bool` seems like a nice resolution to me. no need for new 
> keywords and it reads better than !foo
> 
> On Sun, May 22, 2016 at 3:28 AM, Haravikk via swift-evolution 
> <[email protected] <mailto:[email protected]>> wrote:
> I think this would make more sense if we were to get more characters in 
> operators, such that we could also replace && with and, and || with or, this 
> way we could make not an operator and write expressions like so:
> 
>       if foo and not bar { … }
> 
> Otherwise as others have said this seems strange as a method. If you don’t 
> find the leading exclamation mark very readable then you could instead do:
> 
>       foo != true
> 
> It’s a few more characters, but it exists now and reads logically I think.
> 
>> On 21 May 2016, at 15:50, Антон Миронов via swift-evolution 
>> <[email protected] <mailto:[email protected]>> wrote:
>> 
>> I found negation operator (!) the least detectable among the code. So I’ve 
>> decided to add property “not” to BooleanType (Swift 2.2) or Boolean on 3.0 
>> with extension:
>> 
>> extension BooleanType {
>>      var not: Bool { return !self.boolValue }
>> }
>> 
>> This is code with negation operator:
>>      return !self.lanes[position.y][currentLaneRange].contains(.Gap)
>> 
>> As I sad before negation operation is hard to spot. Moreover at first it 
>> looks like I’m trying to negate self for some reason.
>> 
>> This is code with “not” property:
>>      return self.lanes[position.y][currentLaneRange].contains(.Gap).not
>> 
>> Now it is easy to spot the statement I am actually getting negation of.
>> On my experience negation operator can occasionally be missed while reading 
>> code. This happens less often with “not” property. So I’m proposing to add 
>> this property to standard library and prefer it in most cases.
>> 
>> Thanks,
>> Anton Mironov
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to