[Draft] Introducing Build Configuration Tests for Platform Conditions

Erica_Sadun · March 15, 2016, 4:10pm

I think this one is pretty straightforward, but as always feedback is requested and appreciated.
Let me know if you're okay with the names and the approach and whether there are any technical
barriers that need addressing.

Thanks, -- E

Introducing Build Configuration Tests for Platform Conditions

Proposal: SE-00XX
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<platformconditions.md · GitHub

This proposal introduces configuration test to differentiate platform conditions.

This proposal was discussed on-list in the Introducing Build Configuration Tests for Platform Conditions <applewebdata://DAF46169-949E-4C76-B744-5D8AB8E633A8>.

<platformconditions.md · GitHub

Testing for platform conditions is a typical developer task. Although some built-in features like CFByteOrderGetCurrentexist, it seems a natural match to Swift to introduce build configurations specific to common platform conditions.

<platformconditions.md · GitHub Design

This proposal adds the following build configuration tests:

#if endian(big)
#if endian(little)
#if bitwidth(32)
#if bitwidth(64)
<platformconditions.md · GitHub Art

Swift currently supports the following configuration tests:

The literals true and false
The os() function that tests for OSX, iOS, watchOS, tvOS, Linux, Windows, and FreeBSD
The arch() function that tests for x86_64, arm, arm64, i386, powerpc64, and powerpc64le
The swift() function that tests for specific Swift language releases, e.g. swift(>=2.2)
<platformconditions.md · GitHub Considered

There are no alternatives considered.

William_Dillon2 · March 15, 2016, 4:17pm

These are excellent. I wouldn’t have chosen anything differently.

Thanks, Erica!

···

On Mar 15, 2016, at 9:10 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

platformconditions.md · GitHub

I think this one is pretty straightforward, but as always feedback is requested and appreciated.
Let me know if you're okay with the names and the approach and whether there are any technical
barriers that need addressing.

Thanks, -- E

Introducing Build Configuration Tests for Platform Conditions

Proposal: SE-00XX
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<platformconditions.md · GitHub

This proposal introduces configuration test to differentiate platform conditions.

This proposal was discussed on-list in the Introducing Build Configuration Tests for Platform Conditions <applewebdata://16D657C7-581A-4F1A-9FCC-5C777E259D40>.

<platformconditions.md · GitHub

Testing for platform conditions is a typical developer task. Although some built-in features like CFByteOrderGetCurrentexist, it seems a natural match to Swift to introduce build configurations specific to common platform conditions.

<platformconditions.md · GitHub Design

This proposal adds the following build configuration tests:

if endian(big)
if endian(little)
if bitwidth(32)
if bitwidth(64)
<platformconditions.md · GitHub Art

Swift currently supports the following configuration tests:

The literals true and false
The os() function that tests for OSX, iOS, watchOS, tvOS, Linux, Windows, and FreeBSD
The arch() function that tests for x86_64, arm, arm64, i386, powerpc64, and powerpc64le
The swift() function that tests for specific Swift language releases, e.g. swift(>=2.2)
<platformconditions.md · GitHub Considered

There are no alternatives considered.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Shawn_Erickson · March 15, 2016, 4:40pm

I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I
believe swift attempts to avoid that by defining either 32 bit or 64 bit
model. If that is universally the case then I think bitwidth is fine. If
not then pointerwidth may be more correct. Those bridging to C would have
to consider information from the C world to deal with the variations of
type size based on platform and 32/64.

-Shawn

William_Dillon2 · March 15, 2016, 4:51pm

The vast majority of special cases I’ve seen and written are due to the size of Int, not a pointer per se. To clear up the confusion, how about we rename bitwidth to intwidth or intsize?

- Will

···

On Mar 15, 2016, at 9:40 AM, Shawn Erickson via swift-evolution <swift-evolution@swift.org> wrote:

I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I believe swift attempts to avoid that by defining either 32 bit or 64 bit model. If that is universally the case then I think bitwidth is fine. If not then pointerwidth may be more correct. Those bridging to C would have to consider information from the C world to deal with the variations of type size based on platform and 32/64.

-Shawn
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Erica_Sadun · March 15, 2016, 4:59pm

Before going any further, is it possible to hop over to the [DRAFT] Introducing a Debug Build Configuration Test, and pick up where Joe Groff just left off?
Looks like things may not be as clear and orthogonal as I initially thought and it would help (a lot) if the discussion was all in one place.

Thanks! -- E

···

On Mar 15, 2016, at 10:51 AM, William Dillon <william@housedillon.com> wrote:

The vast majority of special cases I’ve seen and written are due to the size of Int, not a pointer per se. To clear up the confusion, how about we rename bitwidth to intwidth or intsize?

- Will

On Mar 15, 2016, at 9:40 AM, Shawn Erickson via swift-evolution <swift-evolution@swift.org> wrote:

I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I believe swift attempts to avoid that by defining either 32 bit or 64 bit model. If that is universally the case then I think bitwidth is fine. If not then pointerwidth may be more correct. Those bridging to C would have to consider information from the C world to deal with the variations of type size based on platform and 32/64.

-Shawn
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Shawn_Erickson · March 15, 2016, 5:06pm

I am curious to see some examples of checking Int size to better understand
the situation.

-Shawn

···

On Tue, Mar 15, 2016 at 9:51 AM William Dillon <william@housedillon.com> wrote:

The vast majority of special cases I’ve seen and written are due to the
size of Int, not a pointer per se. To clear up the confusion, how about we
rename bitwidth to intwidth or intsize?

- Will

> On Mar 15, 2016, at 9:40 AM, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I
believe swift attempts to avoid that by defining either 32 bit or 64 bit
model. If that is universally the case then I think bitwidth is fine. If
not then pointerwidth may be more correct. Those bridging to C would have
to consider information from the C world to deal with the variations of
type size based on platform and 32/64.

Shawn_Erickson · March 15, 2016, 8:40pm

Thanks! ...that muddies the water for me more. :)

Who are the users of these platform conditionals? I would assume most
likely folks that are interfacing swift code with C code? In side of the
Swift "sandbox" you should be isolated otherwise, right?

If that is the case then the width of various C types change depending on
OS/OS variant, CPU architecture and potentially other factors. It seems
like conditional evaluating the size of given standard C type may be needed?

bitwidth(cptr: 32/64)
bitwidth(cint: 32/64)
bitwidth(clong: 32/64)
bitwidth(cdouble: 32/64)
etc.

-Shawn

···

On Tue, Mar 15, 2016 at 1:15 PM William Dillon <william@housedillon.com> wrote:

Here’s an example of the kind of thing that’s common: 22 days ago
<Foundation fixes for 32-bit systems and more by hpux735 · Pull Request #264 · apple/swift-corelibs-foundation · GitHub;
There’s another good one in NSRange:
https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRange.swift#L90-L94
There are FAR too many to list in stdlib, runtime, and (compiler) tests.

- Will

On Mar 15, 2016, at 10:06 AM, Shawn Erickson <shawnce@gmail.com> wrote:

On Tue, Mar 15, 2016 at 9:51 AM William Dillon <william@housedillon.com> > wrote:

The vast majority of special cases I’ve seen and written are due to the
size of Int, not a pointer per se. To clear up the confusion, how about we
rename bitwidth to intwidth or intsize?

- Will

> On Mar 15, 2016, at 9:40 AM, Shawn Erickson via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> I guess the fuzziness in my mind is when considering LP64, LLP64, etc.
I believe swift attempts to avoid that by defining either 32 bit or 64 bit
model. If that is universally the case then I think bitwidth is fine. If
not then pointerwidth may be more correct. Those bridging to C would have
to consider information from the C world to deal with the variations of
type size based on platform and 32/64.

I am curious to see some examples of checking Int size to better
understand the situation.

-Shawn