Swift 3: Int Is Not Convertible to Bool in Bitwise Operation

Swift 3: Int is not convertible to Bool in bitwise operation

Unlike in C where you can write...

if (x) { }

... which is really a non-zero check:

if (x != 0) { }

You must test for a boolean condition in Swift. Add != 0 to your statement:

if 10 & (1<<18) != 0 {
    return
}

Getting bit-pattern of bool in Swift

@martin-r’s answer is more fun :-), but this can be done in a playground.

// first check this is true or you’ll be sorry...
sizeof(Bool) == sizeof(UInt8)

let t = unsafeBitCast(true, UInt8.self)   // = 1
let f = unsafeBitCast(false, UInt8.self)  // = 0

Swift 3: Converting numeric string to Bool, getting false for invalid values

For that you can use Nil-Coalescing Operator.

let boolValue = (Int(stringValue) ?? 0) != 0

C to Swift bitwise operations

When it comes to integers, anything that is not 0 is considered true in C. Swift requires a boolean value so you have to add != 0. For example:

C:     if c1 & c2 & c3 & c4 & c5 & 0xf000
Swift: if c1 & c2 & c3 & c4 & c5 & 0xf000 != 0

C:     if (s = unique5[q])
Swift: if let s = unique5[q] where s != 0

Try this:

func eval_5hand_fast(c1: Int, c2: Int, c3: Int, c4: Int, c5: Int) -> Int {

    var q: Int = (c1 | c2 | c3 | c4 | c5) >> 16
    var s: Int8
    if c1 & c2 & c3 & c4 & c5 & 0xf000 != 0 {
        return flushes[q]
    }
    if let s = unique5[q] where s != 0 {
        return s
    }
    return hash_values[find_fast((c1 & 0xff) * (c2 & 0xff) * (c3 & 0xff) * (c4 & 0xff) * (c5 & 0xff))]
}

func find_fast(var u: UInt) -> UInt {
    var a, b, r: UInt
    u += 0xe91aaa35
    u ^= u >> 16
    u += u << 8
    u ^= u >> 4
    b  = (u >> 8) & 0x1ff
    a  = (u + (u << 2)) >> 19
    r  = a ^ hash_adjust[b]
    return r;
}

Combining multiple Bool return values without shortcircuiting

What you were doing in Objective-C was not "elegant". It was skanky and you shouldn't have been doing it. If you want to call three methods, just call those three methods! But forming a boolean expression, you should use the logical operators, not the bitwise operators. So, for example:

let (ok1, ok2, ok3) = (a.isBool(), b.isBool(), c.isBool())
let ok = ok1 && ok2 && ok3

JSONModel incorrectly converting 'T' to '0' on 32-bit devices

In the project that you have linked, the BOOLFromNSString method is as follows:

-(NSNumber*)BOOLFromNSString:(NSString*)string
{
  if (string != nil && 
    ([string caseInsensitiveCompare:@"true"] == NSOrderedSame ||
    [string caseInsensitiveCompare:@"yes"] == NSOrderedSame)) {
    return [NSNumber numberWithBool:YES];
  }
  return [NSNumber numberWithBool: ([string intValue]==0)?NO:YES];
}

This means that it is expected to return YES for the following case-insensitive values: true, yes, [any number that isn't 0].

The fact that it returns YES for T on any platform is magic, not "correct". You should use one of the expected values.

---

Edit: Your subclass:

#import "JSONModelTransformations/JSONValueTransformer.h"

@interface MyParser : JSONValueTransformer
@end

@implementation MyParser
- (NSNumber *)BOOLFromNSString:(NSString *)string {
  if (string != nil && [string caseInsensitiveCompare:@"t"] == NSOrderedSame) {
    return [NSNumber numberWithBool:YES];
  }
  return [super BOOLFromNSString:string];
}
@end

Cleanly converting an Objective-C Boolean to a Swift Bool?

UTTypeConformsTo() returns a Boolean, which is a type alias for Int8 and not directly
convertible to Bool. The simplest way would be

let testBool : Bool = UTTypeConformsTo(utiCF, typeCF) != 0

where the type annotation is actually not necessary:

let testBool = UTTypeConformsTo(utiCF, typeCF) != 0

Understanding bitwise XOR (^) with boolean variables

As bool is a narrower type than an int, both arguments are implicitly converted to an int prior to the XOR being evaluated. true assumes the value 1, and false assumes the value 0.

If that result is non-zero then the if body runs, and that happens if and only if body1awake is not equal to body2awake.

So perhaps the equivalent

if (body1awake != body2awake)

would have been better. If the author thinks their way is faster then they need a stern talking to with compiler optimisations and as-if rule being introduced into the conversation.

---

Related Topics