Regarding "Bitwidth describes the number of bits used to represent a number. This proposal introduces a bitwidth test with two options: 32 and 64."...
I don't fully understand how this will work or in general how it will be used. - "used to represent a number"... What "number" (e.g. what type)? - Is it just the width a pointer? Does this only relate to UnsafePointer? - Is it the width of something in the C realm? (e.g. CLong/long, CLongLong/long long, etc.) - How does it deal with variations of 64bit-ness of platforms (e.g. LP64, LLP64, etc.) - Inside of Swift (pure swift) does it serve any purpose not covered by the properties exposed on the various numeric types? - If for use in bridging C, etc. can it not be dealt with on the C side of things? I personally think it needs to be specifically about pointer width or it needs to allow for a compile query of the size of a given platform variable width type (including C mapped ones). -Shawn On Thu, Jun 16, 2016 at 9:49 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > This is an omnibus conditional compilation block proposal. It is built out > of Swift Evolution community requests and discussions dating back on > various threads to the genesis of the list. > > > - This draft does not include tests for debug conditions. That was > pitched under separate cover using runtime functions instead of conditional > compilation blocks. > - This draft does not include tests for OS versions, as that seems to > be better addressed using the existing availability tests. > - This draft is rewritten with respect to Jordan Rose's "Rename "build > configurations" to "conditional compilation blocks"" swift commit > > <https://github.com/apple/swift/commit/6272941c5cba9581a5ee93d92a6ee66e28c1bf13> > from > 12 February (rdar://problem/19812930). > - It is offered as an omnibus because all the tests fall under the > same "conditional compilation block" umbrella. Using an omnibus reduces > list traffic and demands on core team resources. It's understood that the > proposal is likely to be accepted with modifications (or rejected as a > whole) due to the multiple tests. > > > -- Erica > > gist: https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298 > > Enhancing the Platform Configuration Test Suite for Conditional > Compilation Blocks > > - Proposal: TBD > - Author: Erica Sadun <http://github.com/erica> > - Status: TBD > - Review manager: TBD > > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#introduction> > Introduction > > This proposal introduces additional configuration tests to differentiate > platform conditions in conditional compilation blocks. > > This proposal was first discussed on-list in the [Draft] Introducing > Build Configuration Tests for Platform Conditions > <http://thread.gmane.org/gmane.comp.lang.swift.evolution/12140/focus=12267> > thread > and then re-pitched in TBD <https://gist.github.com/erica/TBD>. > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#note>Note > > The term "build configuration" is subsumed by "conditional compilation > block". See this accepted patch > <https://github.com/apple/swift/commit/6272941c5cba9581a5ee93d92a6ee66e28c1bf13> > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#motivation> > Motivation > > Testing for platform conditions is a typical developer task. Although some > built-in features like CFByteOrderGetCurrentexist, it seems a natural > match for Swift to introduce conditional compilation blocks specific to > common platform conditions. > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#current-art>Current > Art > > Swift currently supports the following platform configuration tests, > defined in lib/Basic/LangOptions.cpp. > > - The literals true and false > - The os() function that tests for OSX, iOS, watchOS, tvOS, Linux, > Windows, Android, and FreeBSD > - The arch() function that tests for x86_64, arm, arm64, i386, > powerpc64, s390x, and powerpc64le > - The swift() function that tests for specific Swift language > releases, e.g. swift(>=2.2) > > The following platform configuration test has been accepted in SE-0075 > <https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md> > but > not yet implemented: > > - The canImport() function that tests whether specific modules can be > imported. > > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#detailed-design>Detailed > Design > > This proposal introduces several platform condition tests for use in > conditional compilation blocks: endianness, bitwidth, vendor, objc interop, > and simulator. > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#endianness> > Endianness > > Endianness refers to the byte order used in memory. This proposal exposes > endian test conditions, promoting them from private underscored names to > public developer-referencable ones. > > // Set the "_endian" platform condition. > switch (Target.getArch()) { > case llvm::Triple::ArchType::arm: > case llvm::Triple::ArchType::thumb: > addPlatformConditionValue("_endian", "little"); > break; > case llvm::Triple::ArchType::aarch64: > addPlatformConditionValue("_endian", "little"); > break; > case llvm::Triple::ArchType::ppc64: > addPlatformConditionValue("_endian", "big"); > break; > case llvm::Triple::ArchType::ppc64le: > addPlatformConditionValue("_endian", "little"); > break; > case llvm::Triple::ArchType::x86: > addPlatformConditionValue("_endian", "little"); > break; > case llvm::Triple::ArchType::x86_64: > addPlatformConditionValue("_endian", "little"); > break; > case llvm::Triple::ArchType::systemz: > addPlatformConditionValue("_endian", "big"); > break; > default: > llvm_unreachable("undefined architecture endianness"); > > Under this proposal _endian is renamed to endian and made a public API. > > Use: > > #if endian(big) > // Big endian code > #endif > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#bitwidth> > Bitwidth > > Bitwidth describes the number of bits used to represent a number. This > proposal introduces a bitwidth test with two options: 32 and 64. > > Use: > > #if bitwidth(64) > // 64-bit code > #endif > > List members briefly discussed whether it was better to measure pointer > width or the size of Int. William Dillon suggested renaming bitwidth to > either intwidth or intsize. Brent Royal-Gordon suggests intbits. > Alternatives include bitsand bitsize. This proposal avoids wordbits because > of the way, for example, Intel ends up doing “dword”, “qword”, and so forth > for backwards compatibility. > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#vendor> > Vendor > > A vendor describes the corporate or other originator of a platform. This > proposal introduces a test that returns platform vendor, with one option at > this time: Apple. Apple deployment provides an umbrella case for wide > range of coding norms that may not be available on non-Apple platforms. > This "family of targets" provides a simpler test than looking for specific > modules or listing individual operating systems, both of which provide > fragile approaches to this requirement. > > This call would be supported in Swift's source-code by the existing > private getVendor() used in lib/Basic/LangOptions.cpp. > > Use: > > #if vendor(Apple) > // Code specific to Apple platform deployment > #endif > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#interop> > Interop > > Swift's Objective-C compatibility enables developers to build > mix-and-match projects with a mixed-language codebase. This proposal > introduces a test to determine whether the Objective-C runtime is available > for use. This test uses only one option, objc, although it could > potentially expand to other scenarios, such as jvm, clr, and C++. > > if (EnableObjCInterop) > addPlatformConditionValue("_runtime", "_ObjC");else > addPlatformConditionValue("_runtime", "_Native") > > Use: > > #if interop(objc) > // Code that depends on Objective-C > #endif > > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#simulator-conditions>Simulator > Conditions > > Xcode simulators enable developers to test code on a wide range of > platforms without directly using physical devices. A simulator may not > offer the full suite of modules available with device deployment or provide > device-only hardware hooks like GPS. This proposal introduces a test for > simulator platform conditions, enabling developers to omit references to > unsupported features. It offers two options: simulator and device. > > bool swift::tripleIsAnySimulator(const llvm::Triple &triple) { > return tripleIsiOSSimulator(triple) || > tripleIsWatchSimulator(triple) || > tripleIsAppleTVSimulator(triple); > } > > This proposal uses a targetEnvironment test as target or platform are too > valuable burn on this test. > > Use: > > #if targetEnvironment(simulator) > // Code specific to simulator use > #endif > > This condition test would reduce the fragility and special casing > currently in use: > > #if (arch(i386) || arch(x86_64)) && os(iOS) > print("Probably simulator") > #endif > > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#impact-on-existing-code>Impact > on Existing Code > > This proposal is additive and should not affect existing code. Some > developers may refactor code as in the case of the simulator/device test. > > <https://gist.github.com/erica/c9c11b540a2439696b2f514c2ffc6298#alternatives-considered>Alternatives > Considered > Not accepting this proposal > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution