ObjCBool: Add boolValue property

[spevans]

• Update uses of Bool to ObjCBool where appropriate

Found after testing Darwin compatibility where the ObjCBool type has a boolValue property

[spevans]

@phausler Does this look correct?

[spevans]

@swift-ci please test

[alblue]

What advantages/disadvantages does this have? The code looks less Swifty than before with the introduction of ObjCBool in the places that it has been used.

[ianpartridge]

Can/should this be a struct as documented? https://developer.apple.com/documentation/objectivec/objcbool

[spevans]

@alblue This is part of making the unit tests run on native Darwin Foundation.
@ianpartridge I suspect yes, it may require a full implementation to match Darwin's foundation, I will investigate it.

[phausler]

ObjCBool is defined in https://github.com/apple/swift/blob/master/stdlib/public/SDK/ObjectiveC/ObjectiveC.swift#L27

we should probably lift the implementation instead of aliasing Bool

[spevans]

I converted ObjCBool to use the struct version from the stdlib however I don't think its that useful.
Apart from having to update all of the code to use .boolValue I don't think it provides any benefit and is now burdened by using @_fixed_layout and @_transparent which may not be allowed.
The origin commit just fixed up some tests so that they would work under Darwin compatibility, so the only possible value I can see with this change is that a library would possibly be binary compatible between sclf and native Foundation on macOS. I don't see any benefit for non-Darwin platforms.

[spevans]

I had another think about this. The boolValue is only required for the tests (to be compatible with native Darwin Foundation) not in the actual runtime or implementation files.
I think the original extension and property should be added just to a test file and not exported in the runtime. Its a rather meaningless type for non-ObjC platforms, and ObjC platforms will use the real ObCBool provided by the core runtime.

[phausler]

it doesn't have much meaning once compiled but the one thing it does do is keep us honest for compatibility - so in the spirit of the project (to offer cross platform compatibility with the fundamentals offered by Foundation and cross platform interoperation) it seems to be the best approach even though it is named perhaps inappropriately (more a naming choice by the standard library) it statically enforces our goals to offer the same API surface area for things that can be represented as a cross platform interface.

[phausler]

looks good to me, I think this will keep us honest for our changes.

[phausler]

are these functions really needed? traditionally we like to avoid underscore public methods unless absolutely needed (like the reference to structure bridge methods) for functionality.

[ianpartridge]

I don't understand why this is necessary... It's only going to get passed to an API which takes bool so can't it stay as bool?

[spevans]

Because it calls
let _ = FileManager.default.fileExists(atPath: absolutePath, isDirectory: &isDir)
and thats defined as:
open func fileExists(atPath path: String, isDirectory: UnsafeMutablePointer<ObjCBool>?) -> Bool

and ObjCBool is not a simple Bool anymore.

[ianpartridge]

Ohhhh, thanks.

[spevans]

@phausler I removed the_convertBoolToObjCBool and _convertObjCBoolToBool and rebased

[spevans]

@swift-ci please test and merge