[META] Re-invigorating the compiler directive discussion

I would like to bring the compiler directive discussion back to life. Introducing new conditionals
has been raised at several points, poked at, and then died down and gone nowhere.

Discussed at a variety of times directives mentioned on-list include

Apple/Non-Apple Platform to differentiate imports. The current art allows if os(Linux) but does not categorize Apple platforms as an entire coherent group. #if os(Darwin) // os(iOS) || os(OSX) || os(watchOS) || os(tvOS), expandable for any new OS's. Kevin Ballard writes, "Without this, I think people are going to be tempted to write if !os(Linux) instead of writing out all 4 Apple platforms, and this is unfortunate because it makes the assumption that Linux is the only non-Apple platform, and that's simply not true."
Common UIKit platform: #if os(iOS) || os(tvOS) or general module availability: #if available(AppKit), #if available(UIKit) (Plus a proposal to replace os with platform) ("Is the target a common UIKit platform? Can it import UIKit?")
Linux distribution check ("Is this target a specific Linux distro? Is it at least this distro or later?")
Is this a Unixy-platform (vs, for example, running on Windows would not be)
What BSD characteristics does this platform support?
Simulator/Physical destinations ("Is the target a simulator environment or physical device?")
Debug/Release builds (bypassing the need for -DDEBUG flags) ("Is the target in Debug or Release mode?")
DebugAsserts/ReleaseAsserts/FastAsserts
General conditional flag detection #if config(Debug)
Test-supporting ("Is the target built for running tests?)
Big-or-little endian
Architecture families: Is this a 32-or-64-bit target
Architecture subtypes
Signed-or-unsigned char
Existing build configurations include os() (OSX, iOS, watchOS, tvOS, Linux) and arch() (X86_64, arm, arm64, i386), the literals true and false, and testing for command-line flags defined using -D <#flag#>.

I believe these directives involve relatively minor changes, should be easy to implement, and
can be extended over time as needed. It would probably be best to get a sense of which
ones the dev community *really* want and need and push on those to avoid clutter,
but I’d hate to see these languish without getting a proper discussion.

Core team members: Would it best to propose individual changes,
create a small groups of related items, or try to push through a large suite?

-- E

Thanks for this, Erica. A huge +1 from me.

- Will

···

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

I would like to bring the compiler directive discussion back to life. Introducing new conditionals
has been raised at several points, poked at, and then died down and gone nowhere.

Discussed at a variety of times directives mentioned on-list include

Apple/Non-Apple Platform to differentiate imports. The current art allows if os(Linux) but does not categorize Apple platforms as an entire coherent group. if os(Darwin) // os(iOS) || os(OSX) || os(watchOS) || os(tvOS), expandable for any new OS's. Kevin Ballard writes, "Without this, I think people are going to be tempted to write if !os(Linux) instead of writing out all 4 Apple platforms, and this is unfortunate because it makes the assumption that Linux is the only non-Apple platform, and that's simply not true."
Common UIKit platform: if os(iOS) || os(tvOS) or general module availability: if available(AppKit), if available(UIKit) (Plus a proposal to replace os with platform) ("Is the target a common UIKit platform? Can it import UIKit?")
Linux distribution check ("Is this target a specific Linux distro? Is it at least this distro or later?")
Is this a Unixy-platform (vs, for example, running on Windows would not be)
What BSD characteristics does this platform support?
Simulator/Physical destinations ("Is the target a simulator environment or physical device?")
Debug/Release builds (bypassing the need for -DDEBUG flags) ("Is the target in Debug or Release mode?")
DebugAsserts/ReleaseAsserts/FastAsserts
General conditional flag detection if config(Debug)
Test-supporting ("Is the target built for running tests?)
Big-or-little endian
Architecture families: Is this a 32-or-64-bit target
Architecture subtypes
Signed-or-unsigned char
Existing build configurations include os() (OSX, iOS, watchOS, tvOS, Linux) and arch() (X86_64, arm, arm64, i386), the literals true and false, and testing for command-line flags defined using -D <#flag#>.

I believe these directives involve relatively minor changes, should be easy to implement, and
can be extended over time as needed. It would probably be best to get a sense of which
ones the dev community *really* want and need and push on those to avoid clutter,
but I’d hate to see these languish without getting a proper discussion.

Core team members: Would it best to propose individual changes,
create a small groups of related items, or try to push through a large suite?

-- E

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

Agreed, thanks for tracking this, Erica. I want to see this move forward.

I'd personally like to see:
- os(darwin) or Apple platform grouping
- simulator vs physical device
- test supporting
- module / UIKit availability

- Step

···

On Mar 10, 2016, at 9:26 PM, William Dillon via swift-evolution <swift-evolution@swift.org> wrote:

Thanks for this, Erica. A huge +1 from me.

- Will

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

I would like to bring the compiler directive discussion back to life. Introducing new conditionals
has been raised at several points, poked at, and then died down and gone nowhere.

Discussed at a variety of times directives mentioned on-list include

Apple/Non-Apple Platform to differentiate imports. The current art allows if os(Linux) but does not categorize Apple platforms as an entire coherent group. if os(Darwin) // os(iOS) || os(OSX) || os(watchOS) || os(tvOS), expandable for any new OS's. Kevin Ballard writes, "Without this, I think people are going to be tempted to write if !os(Linux) instead of writing out all 4 Apple platforms, and this is unfortunate because it makes the assumption that Linux is the only non-Apple platform, and that's simply not true."
Common UIKit platform: if os(iOS) || os(tvOS) or general module availability: if available(AppKit), if available(UIKit) (Plus a proposal to replace os with platform) ("Is the target a common UIKit platform? Can it import UIKit?")
Linux distribution check ("Is this target a specific Linux distro? Is it at least this distro or later?")
Is this a Unixy-platform (vs, for example, running on Windows would not be)
What BSD characteristics does this platform support?
Simulator/Physical destinations ("Is the target a simulator environment or physical device?")
Debug/Release builds (bypassing the need for -DDEBUG flags) ("Is the target in Debug or Release mode?")
DebugAsserts/ReleaseAsserts/FastAsserts
General conditional flag detection if config(Debug)
Test-supporting ("Is the target built for running tests?)
Big-or-little endian
Architecture families: Is this a 32-or-64-bit target
Architecture subtypes
Signed-or-unsigned char
Existing build configurations include os() (OSX, iOS, watchOS, tvOS, Linux) and arch() (X86_64, arm, arm64, i386), the literals true and false, and testing for command-line flags defined using -D <#flag#>.

I believe these directives involve relatively minor changes, should be easy to implement, and
can be extended over time as needed. It would probably be best to get a sense of which
ones the dev community *really* want and need and push on those to avoid clutter,
but I’d hate to see these languish without getting a proper discussion.

Core team members: Would it best to propose individual changes,
create a small groups of related items, or try to push through a large suite?

-- E

_______________________________________________
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

Here's a first draft.

Start kicking away:

Expanding Build Configuration Tests

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

Expanding the configuration test suite to include Darwin support (to test for Apple platforms) was first introduced <http://article.gmane.org/gmane.comp.lang.swift.evolution/7516/match=darwin&gt; on the Swift-Evolution list by Kevin Ballard. His idea was greeted warmly and quickly expanded upon by developers looking to introduce the kinds of conditional configuration they're used to in other languages. This proposal introduces a subset of the configurations requested on that thread.

SE-0020 <https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md&gt; added #if swift to enable code to compile with specific versions of the Swift language. This proposal introduces several further compile-time configuration, adding configuration tests for x, y, z, and w.

This proposal was discussed on-list in the <applewebdata://F45129A6-479E-49DD-A37D-349C0AA78CBA>thread.

<builds.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, and Linux
The arch() function that tests for x86_64, arm, arm64, and i386
The swift() function that tests for specific Swift language releases, e.g. swift(>=2.2)
<builds.md · GitHub

As Swift expands to a growing developer base and to new platforms, the existing suite of configuration tests begins to show strain. Shortcuts taking advantage of current limitations introduce fragility. For example, testing #if os(iOS) || os(OSX) || os(watchOS) || os(tvOS) may miss new platform targets and #if !os(Linux) may introduce errors should Swift extend to other non-Apple platforms, such as Windows.

Swift also misses a built-in #if debug test. Although you can specify command-line flags using -D <#flag#> (e.g. -D debug) and test in-code (#if debug), there's no consistent system-supplied way to perform this test.

This proposal introduces a minimal set of utility configuration tests.

<builds.md · GitHub Design

#if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
#if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
#if target(simulator) and #if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
#if target(32bit) and #if target(64bit) tests for 32 and 64 bit architecture families.
#if target(bigendian) and #if target(littleendian) tests for big and little endianness.
#if config(debug) tests for debug builds.
<builds.md · GitHub

Joe Groff writes, "We specifically avoided making debug/release an #if condition because we considered #if to be the wrong point at which to start conditionalizing code generation for assertions. Though the final executable image's behavior is unavoidably dependent on whether asserts are enabled, we didn't want the SIL for inlineable code to be, since that would mean libraries with inlineable code would need to ship three times the amount of serialized SIL to support the right behavior in -Onone, -O, and -Ounchecked builds. Instead, the standard library has some hidden helper functions, _isDebugAssertConfiguration, _isReleaseAssertConfiguration, and _isFastAssertConfiguration, which are guaranteed to be constant-folded away before final code generation."
Not included in this proposal at this time: "Is the target built for running tests", #if destination() tests for specific destinations, #if destination(BSD), #if destination(Ubuntu, >=14.04) to establish common-ground calls for, for example, BSD destinations or specific Linux distros.

<builds.md · GitHub Considered

There are no alternatives considered.

Comments below

Here's a first draft.

Start kicking away:

Expanding Build Configuration Tests
Proposal: SE-00XX
Author(s): Erica Sadun
Status: TBD
Review manager: TBD
Introduction

Expanding the configuration test suite to include Darwin support (to test for Apple platforms) was first introduced on the Swift-Evolution list by Kevin Ballard. His idea was greeted warmly and quickly expanded upon by developers looking to introduce the kinds of conditional configuration they're used to in other languages. This proposal introduces a subset of the configurations requested on that thread.

SE-0020 added if swift to enable code to compile with specific versions of the Swift language. This proposal introduces several further compile-time configuration, adding configuration tests for x, y, z, and w.

I assume x, y, z, and w are intended to be filled in once the list has settled.

This proposal was discussed on-list in the thread.

Current Art

Swift currently supports the following configuration tests:

The literals true and false
The os() function that tests for OSX, iOS, watchOS, tvOS, and Linux
The arch() function that tests for x86_64, arm, arm64, and i386
The swift() function that tests for specific Swift language releases, e.g. swift(>=2.2)
Motivation

As Swift expands to a growing developer base and to new platforms, the existing suite of configuration tests begins to show strain. Shortcuts taking advantage of current limitations introduce fragility. For example, testing if os(iOS) || os(OSX) || os(watchOS) || os(tvOS) may miss new platform targets and if !os(Linux) may introduce errors should Swift extend to other non-Apple platforms, such as Windows.

Swift also misses a built-in if debug test. Although you can specify command-line flags using -D <#flag#> (e.g. -D debug) and test in-code (if debug), there's no consistent system-supplied way to perform this test.

What do you mean by "this test"? Testing for a built-in configuration (debug) without needing customization?

Also FWIW I am ok with the custom flag approach.( In fact it just occurred to me that I can use the custom flags approach to check for test targets too - nice! )

This proposal introduces a minimal set of utility configuration tests.

Detail Design

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.

Am I reading it right that this would import the framework if the test succeeds?

if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

Wondering if it is better to cover these all in one proposal or chunk them up. Wouldn't want this to become an omnibus proposal and get bogged down. But it makes sense to discuss many of these together.

···

On Mar 12, 2016, at 10:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Note

Joe Groff writes, "We specifically avoided making debug/release an if condition because we considered if to be the wrong point at which to start conditionalizing code generation for assertions. Though the final executable image's behavior is unavoidably dependent on whether asserts are enabled, we didn't want the SIL for inlineable code to be, since that would mean libraries with inlineable code would need to ship three times the amount of serialized SIL to support the right behavior in -Onone, -O, and -Ounchecked builds. Instead, the standard library has some hidden helper functions, _isDebugAssertConfiguration, _isReleaseAssertConfiguration, and _isFastAssertConfiguration, which are guaranteed to be constant-folded away before final code generation."
Not included in this proposal at this time: "Is the target built for running tests", if destination() tests for specific destinations, if destination(BSD), if destination(Ubuntu, >=14.04) to establish common-ground calls for, for example, BSD destinations or specific Linux distros.

Alternatives Considered

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

I agree that expanding our repertoire here is badly needed. I think it'd be better to have a specific if foo(...) name for each combination of independent choices. It's a nice property of our current design that, when you see if foo(X) || foo(Y), you know foo(X) and foo(Y) are mutually exclusive. You'd lose that if you had both target(32bit) and target(bigendian).

-Joe

···

On Mar 12, 2016, at 7:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

SE-0020 <https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md&gt; added if swift to enable code to compile with specific versions of the Swift language. This proposal introduces several further compile-time configuration, adding configuration tests for x, y, z, and w.

I assume x, y, z, and w are intended to be filled in once the list has settled.

Yes.

This is still first draft-y.

Swift also misses a built-in if debug test. Although you can specify command-line flags using -D <#flag#> (e.g. -D debug) and test in-code (if debug), there's no consistent system-supplied way to perform this test.

What do you mean by "this test"? Testing for a built-in configuration (debug) without needing customization?

Also FWIW I am ok with the custom flag approach.( In fact it just occurred to me that I can use the custom flags approach to check for test targets too - nice! )

"There's no consistent system-supplied way to differentiate code meant solely for debug builds".

Better?

if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.

Am I reading it right that this would import the framework if the test succeeds?

I was not intending that this do the import, but test whether the framework/module (probably change this to module) *could* be imported.

if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

Wondering if it is better to cover these all in one proposal or chunk them up. Wouldn't want this to become an omnibus proposal and get bogged down. But it makes sense to discuss many of these together.

I put out a query on-list asking for clarification from the core team. Have not heard a peep. If this gains any momentum, I suspect someone will chime in.

-- E

···

On Mar 12, 2016, at 9:25 PM, Step C <schristopher@bignerdranch.com> wrote:

Ah. I was trying to *reduce* the number of distinct fooities.

if bitwidth(32) and if bitwidth(64) tests for 32 and 64 bit architecture families.
if endian(big) and if endian(little) tests for big and little endianness.
better?

Also, should I break this up into distinct proposals or one core utility group?

-- E

···

On Mar 14, 2016, at 11:28 AM, Joe Groff <jgroff@apple.com> wrote:

On Mar 12, 2016, at 7:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

I agree that expanding our repertoire here is badly needed. I think it'd be better to have a specific if foo(...) name for each combination of independent choices. It's a nice property of our current design that, when you see if foo(X) || foo(Y), you know foo(X) and foo(Y) are mutually exclusive. You'd lose that if you had both target(32bit) and target(bigendian).

-Joe

SE-0020 added if swift to enable code to compile with specific versions of the Swift language. This proposal introduces several further compile-time configuration, adding configuration tests for x, y, z, and w.

I assume x, y, z, and w are intended to be filled in once the list has settled.

Yes.

This is still first draft-y.

Swift also misses a built-in if debug test. Although you can specify command-line flags using -D <#flag#> (e.g. -D debug) and test in-code (if debug), there's no consistent system-supplied way to perform this test.

What do you mean by "this test"? Testing for a built-in configuration (debug) without needing customization?

Also FWIW I am ok with the custom flag approach.( In fact it just occurred to me that I can use the custom flags approach to check for test targets too - nice! )

"There's no consistent system-supplied way to differentiate code meant solely for debug builds".

Better?

Yes.

if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.

Am I reading it right that this would import the framework if the test succeeds?

I was not intending that this do the import, but test whether the framework/module (probably change this to module) *could* be imported.

`if importAvailable(UIKit)`
`if moduleAvailable(UIKit)`
`if canImport(UIKit)` ?

It should say module, good point.

···

El mar 13, 2016, a las 12:57 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> escribió:

On Mar 12, 2016, at 9:25 PM, Step C <schristopher@bignerdranch.com> wrote:

if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

Wondering if it is better to cover these all in one proposal or chunk them up. Wouldn't want this to become an omnibus proposal and get bogged down. But it makes sense to discuss many of these together.

I put out a query on-list asking for clarification from the core team. Have not heard a peep. If this gains any momentum, I suspect someone will chime in.

-- E

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

IMO I'd split it up.

-Joe

···

On Mar 14, 2016, at 10:33 AM, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 14, 2016, at 11:28 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Mar 12, 2016, at 7:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

I agree that expanding our repertoire here is badly needed. I think it'd be better to have a specific if foo(...) name for each combination of independent choices. It's a nice property of our current design that, when you see if foo(X) || foo(Y), you know foo(X) and foo(Y) are mutually exclusive. You'd lose that if you had both target(32bit) and target(bigendian).

-Joe

Ah. I was trying to *reduce* the number of distinct fooities.

if bitwidth(32) and if bitwidth(64) tests for 32 and 64 bit architecture families.
if endian(big) and if endian(little) tests for big and little endianness.
better?

Also, should I break this up into distinct proposals or one core utility group?

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

I agree that expanding our repertoire here is badly needed. I think it'd be better to have a specific if foo(...) name for each combination of independent choices. It's a nice property of our current design that, when you see if foo(X) || foo(Y), you know foo(X) and foo(Y) are mutually exclusive. You'd lose that if you had both target(32bit) and target(bigendian).

-Joe

Ah. I was trying to *reduce* the number of distinct fooities.

if bitwidth(32) and if bitwidth(64) tests for 32 and 64 bit architecture families.
if endian(big) and if endian(little) tests for big and little endianness.
better?

Also, should I break this up into distinct proposals or one core utility group?

IMO I'd split it up.

-Joe

Prepare for deluge. I'll hold off for a day or two just to see if anyone hates any of these or wants them tweaked or sees something else urgent to add.
Otherwise, there has been sufficient enthusiasm on a variety of threads and fora to give me confidence to kickstart 'em.

-- E

···

On Mar 14, 2016, at 11:34 AM, Joe Groff <jgroff@apple.com> wrote:

On Mar 14, 2016, at 10:33 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

On Mar 14, 2016, at 11:28 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Mar 12, 2016, at 7:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Go go go :)

···

Sent from my iPhone

On 14 Mar 2016, at 17:42, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 14, 2016, at 11:34 AM, Joe Groff <jgroff@apple.com> wrote:

On Mar 14, 2016, at 10:33 AM, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 14, 2016, at 11:28 AM, Joe Groff <jgroff@apple.com> wrote:

On Mar 12, 2016, at 7:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

I agree that expanding our repertoire here is badly needed. I think it'd be better to have a specific if foo(...) name for each combination of independent choices. It's a nice property of our current design that, when you see if foo(X) || foo(Y), you know foo(X) and foo(Y) are mutually exclusive. You'd lose that if you had both target(32bit) and target(bigendian).

-Joe

Ah. I was trying to *reduce* the number of distinct fooities.

if bitwidth(32) and if bitwidth(64) tests for 32 and 64 bit architecture families.
if endian(big) and if endian(little) tests for big and little endianness.
better?

Also, should I break this up into distinct proposals or one core utility group?

IMO I'd split it up.

-Joe

Prepare for deluge. I'll hold off for a day or two just to see if anyone hates any of these or wants them tweaked or sees something else urgent to add.
Otherwise, there has been sufficient enthusiasm on a variety of threads and fora to give me confidence to kickstart 'em.

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

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if imports(Darwin) can universally distinguish Apple.
Is this something you support or oppose? If you're against, what platforms would you include in the test suite?

Right now, I'm leaning towards tossing `#if platform()` (it can be brought up again at some later date). Is this something you oppose or support?

-- E

···

On Mar 14, 2016, at 12:20 PM, Goffredo Marocchi <panajev@gmail.com> wrote:

Go go go :)

Sent from my iPhone

On 14 Mar 2016, at 17:42, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Mar 14, 2016, at 11:34 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Mar 14, 2016, at 10:33 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

On Mar 14, 2016, at 11:28 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Mar 12, 2016, at 7:56 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

if platform(Apple) tests for platform families, including Apple, Linux, Unix, Windows
if imports(UIKit) tests for framework support, differentiating, for example, Mac code from iOS and tvOS code.
if target(simulator) and if target(device) represent a common categorization requirement, such as Metal, Keychain, and AVFoundation Camera code.
if target(32bit) and if target(64bit) tests for 32 and 64 bit architecture families.
if target(bigendian) and if target(littleendian) tests for big and little endianness.
if config(debug) tests for debug builds.

I agree that expanding our repertoire here is badly needed. I think it'd be better to have a specific if foo(...) name for each combination of independent choices. It's a nice property of our current design that, when you see if foo(X) || foo(Y), you know foo(X) and foo(Y) are mutually exclusive. You'd lose that if you had both target(32bit) and target(bigendian).

-Joe

Ah. I was trying to *reduce* the number of distinct fooities.

if bitwidth(32) and if bitwidth(64) tests for 32 and 64 bit architecture families.
if endian(big) and if endian(little) tests for big and little endianness.
better?

Also, should I break this up into distinct proposals or one core utility group?

IMO I'd split it up.

-Joe

Prepare for deluge. I'll hold off for a day or two just to see if anyone hates any of these or wants them tweaked or sees something else urgent to add.
Otherwise, there has been sufficient enthusiasm on a variety of threads and fora to give me confidence to kickstart 'em.

-- E
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

There's a direction that we want to move to a unified name for the
libc module for all platform, so "can import Darwin" might not be a
viable long-term strategy.

Dmitri

···

On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if
imports(Darwin) can universally distinguish Apple.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Fair point. Adding back to my to-do list. (Good thing my publisher's online edit system is down and I can't get support. Gives me the free time.)

Thanks for the feedback, -- E

···

On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if
imports(Darwin) can universally distinguish Apple.

There's a direction that we want to move to a unified name for the
libc module for all platform, so "can import Darwin" might not be a
viable long-term strategy.

Dmitri

Sounds like a good direction, but to validate it, could you think of
some things you would write in practice that would be guarded by these
if conditions?

Dmitri

···

On Mon, Mar 14, 2016 at 1:41 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote:

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if
imports(Darwin) can universally distinguish Apple.

There's a direction that we want to move to a unified name for the
libc module for all platform, so "can import Darwin" might not be a
viable long-term strategy.

Dmitri:

Will this do it? platform.md · GitHub

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Dmitri:

Will this do it? platform.md · GitHub

-- E

···

On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote:

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if
imports(Darwin) can universally distinguish Apple.

There's a direction that we want to move to a unified name for the
libc module for all platform, so "can import Darwin" might not be a
viable long-term strategy.

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if
imports(Darwin) can universally distinguish Apple.

There's a direction that we want to move to a unified name for the
libc module for all platform, so "can import Darwin" might not be a
viable long-term strategy.

Dmitri:

Will this do it? platform.md · GitHub

Sounds like a good direction, but to validate it, could you think of
some things you would write in practice that would be guarded by these
if conditions?

Dmitri

Quite frankly, I want to test imports not platforms. Things I care personally about:

* testing imports for differentiating code for tvOS/iOS vs OS X primarily: importtest.md · GitHub
* testing sim/device for camera/keychain: target.md · GitHub
* testing debug (yes, in methods is just peachy fine for me) for better logging mostly: debug.md · GitHub

Things I'm doing as a courtesy for the community that I probably will never use:

* testing platform conditions: platformconditions.md · GitHub

The use cases for this one are clear to me, you can find many in
low-level code. I think the majority of the if's found in the
standard library are either checks for 32/64 bit, or ObjC/Native
runtime, or future-proofing checks for endianness.

* testing for specific platform deployment: platform.md · GitHub

-- E, who is still ready and willing to toss the last (platform(Apple)) of these if there's no good use-case motivating it.

It is not that I'm saying that there is no good use case, it is just
that they are not obvious to me. Here's something I could imagine
happening:

if platform(Unix)
use system()
#else if platform(Windows)
use CreateProcessEx
#else
error "unknown platform"
#endif

But I'm not sure that "Unix-like" and "Windows-like" are precise
enough to write the kinds of checks you would want to write in
low-level code.

Dmitri

···

On Mon, Mar 14, 2016 at 2:23 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 14, 2016, at 3:12 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Mon, Mar 14, 2016 at 1:41 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org> wrote:

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Quite frankly, I want to test imports not platforms. Things I care personally about:

* testing imports for differentiating code for tvOS/iOS vs OS X primarily: importtest.md · GitHub
* testing sim/device for camera/keychain: target.md · GitHub
* testing debug (yes, in methods is just peachy fine for me) for better logging mostly: debug.md · GitHub

Things I'm doing as a courtesy for the community that I probably will never use:

* testing platform conditions: platformconditions.md · GitHub
* testing for specific platform deployment: platform.md · GitHub

-- E, who is still ready and willing to toss the last (platform(Apple)) of these if there's no good use-case motivating it.

···

On Mar 14, 2016, at 3:12 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Mar 14, 2016 at 1:41 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org> wrote:

Question to everyone with regard to `#if platform()`:

Right now, I'm leaning towards tossing `#if platform()` since if
imports(Darwin) can universally distinguish Apple.

There's a direction that we want to move to a unified name for the
libc module for all platform, so "can import Darwin" might not be a
viable long-term strategy.

Dmitri:

Will this do it? platform.md · GitHub

Sounds like a good direction, but to validate it, could you think of
some things you would write in practice that would be guarded by these
if conditions?

Dmitri

That's a good enough reason for me to back burner this until someone
has a concrete use.

I'm not deleting it (unless GitHub goes into receivership and shuts down)
but I'm not inclined to present it as a pull request for a full proposal.

Thank you for the feedback, I am going to update and add this bit it in just in case it gets
new life somewhere in the future. So the end result is not so much "toss it" as "defer it".

-- E

···

On Mar 14, 2016, at 4:03 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
The use cases for this one are clear to me, you can find many in
low-level code. I think the majority of the if's found in the
standard library are either checks for 32/64 bit, or ObjC/Native
runtime, or future-proofing checks for endianness.

* testing for specific platform deployment: platform.md · GitHub

-- E, who is still ready and willing to toss the last (platform(Apple)) of these if there's no good use-case motivating it.

It is not that I'm saying that there is no good use case, it is just
that they are not obvious to me. Here's something I could imagine
happening:

if platform(Unix)
use system()
#else if platform(Windows)
use CreateProcessEx
#else
error "unknown platform"
#endif

But I'm not sure that "Unix-like" and "Windows-like" are precise
enough to write the kinds of checks you would want to write in
low-level code.