I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
On Oct 24, 2017, at 8:05 PM, Graydon Hoare via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
Seems useful and well thought-out. The name is justifiable and sufficiently
clear.
···
On Tue, Oct 24, 2017 at 10:05 PM, Graydon Hoare via swift-evolution < swift-evolution@swift.org> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica
Sadun posted last year, that cleans up a slightly messy idiomatic use of
conditional compilation in libraries. The effects should be quite limited;
I'd call it a "standard library" addition except that the repertoire of
compiler-control statements isn't strictly part of the stdlib.
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.
- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).
- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…
- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?
Karl
···
On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
The arguments to platform conditions aren't keywords; it's true that they're unquoted identifiers but they're treated more like contextual keywords or predefined constants: they're only defined in the argument positions of the conditions they're associated with.
Fwiw, Haiku is already in the list of accepted identifiers for the os() condition (proposal updated to reflect this):
-Graydon
···
On Oct 24, 2017, at 8:49 PM, David Sweeris <davesweeris@mac.com> wrote:
On Oct 24, 2017, at 8:05 PM, Graydon Hoare via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
Theoretically, sure. I think that would not be congruent with the existing approach of having one platform condition per component of the triple, though (arch, os). Nor would it let one independently test for simulator-ness without concern for the OS (unless we were to introduce yet another notation, such as os(*, simulator)) I think in general it's simplest if we keep it as its own platform condition.
-Graydon
···
On Oct 24, 2017, at 11:14 PM, Ben Rimmington <me@benrimmington.com> wrote:
Could this be an extra parameter for the os() platform condition?
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and device. This is an unfortunate distinction that ideally should not exist in a simulator, but unfortunately such cases do exist.
(This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)
-BJ
···
On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.
- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).
- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…
- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?
Karl
On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution@swift.org> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
it’s not like I don’t understand when you’d want some different behaviour in a program to account for the simulator’s environment. I just wonder if it’s worth being a built-in part of the language. To me, it feels like something better suited to an ad-hoc build option or global constant.
OS, CPU architecture and endianness are of a different ‘level', IMO. They are typically only useful for very low-level operations (especially once we have #canImport - I expect that to replace most uses of #os with a better, higher-level abstraction).
Really, I think the current TARGET_OS_SIMULATOR compile-time variable is the best approach. Perhaps it could be renamed or aliased to sound nicer from cross-platform code, but I’m not sure it really deserves to be part of the language.
On 26. Oct 2017, at 15:36, BJ Homer via swift-evolution <swift-evolution@swift.org> wrote:
Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and device. This is an unfortunate distinction that ideally should not exist in a simulator, but unfortunately such cases do exist.
(This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)
-BJ
On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.
- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).
- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…
- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?
Karl
On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
it’s not like I don’t understand when you’d want some different behaviour in a program to account for the simulator’s environment. I just wonder if it’s worth being a built-in part of the language. To me, it feels like something better suited to an ad-hoc build option or global constant.
OS, CPU architecture and endianness are of a different ‘level', IMO. They are typically only useful for very low-level operations (especially once we have #canImport - I expect that to replace most uses of #os with a better, higher-level abstraction).
I respectfully disagree that it’s a different “level". Architecture is an axis of configuration. OS is an axis of configuration. Target (device vs simulator/emulator) is just another axis of configuration.
Dave
···
On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
Really, I think the current TARGET_OS_SIMULATOR compile-time variable is the best approach. Perhaps it could be renamed or aliased to sound nicer from cross-platform code, but I’m not sure it really deserves to be part of the language.
On 26. Oct 2017, at 15:36, BJ Homer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and device. This is an unfortunate distinction that ideally should not exist in a simulator, but unfortunately such cases do exist.
(This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)
-BJ
On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.
- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).
- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…
- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?
Karl
On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
it’s not like I don’t understand when you’d want some different behaviour in a program to account for the simulator’s environment. I just wonder if it’s worth being a built-in part of the language. To me, it feels like something better suited to an ad-hoc build option or global constant.
OS, CPU architecture and endianness are of a different ‘level', IMO. They are typically only useful for very low-level operations (especially once we have #canImport - I expect that to replace most uses of #os with a better, higher-level abstraction).
I respectfully disagree that it’s a different “level". Architecture is an axis of configuration. OS is an axis of configuration. Target (device vs simulator/emulator) is just another axis of configuration.
Dave
Yeah, but by extension, every since compile-time flag is also an “axis of configuration”. What makes these few worthy of special language integration and compiler support?
I think OS and architecture are both more fundamental and universal than whether you’re running on a simulator or real device.
- Karl
···
On 26. Oct 2017, at 17:13, Dave DeLong via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Really, I think the current TARGET_OS_SIMULATOR compile-time variable is the best approach. Perhaps it could be renamed or aliased to sound nicer from cross-platform code, but I’m not sure it really deserves to be part of the language.
On 26. Oct 2017, at 15:36, BJ Homer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and device. This is an unfortunate distinction that ideally should not exist in a simulator, but unfortunately such cases do exist.
(This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)
-BJ
On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.
- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).
- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…
- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?
Karl
On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi,
I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
The "environment" field is an optional 4th component of the (not-quite-accurately-named) target-triple. This is not new, it's a thing lots of toolchains have some more-or-less standard support for (different toolchains use it for different purposes: simulator-ness, ABI, libc variation, etc.)
Swift's grammar for compilation conditions[1] provides three different types of leaf node:
- Boolean literals
- Identifiers, representing user-provided ("-D") command-line flags
- Platform conditions, representing language version and 3 existing target-triple components
There's currently no way to write a compilation condition that depends on the 4th field (environment) of the target-triple. This proposal is to surface that 4th field in the same place the other 3 fields are surfaces: as a platform condition.
Conflated with this, the conversation in this thread seems to have ventured into asking -- independently of the question of how to express the environment field as a compilation condition -- whether it's right to express simulator-ness as a target-triple component at all, rather than as a preprocessor symbol. This ship has, however, already sailed: a patch expressing this choice entered LLVM a week ago[2], on the justification that the simulators are literally separate SDKs: from the perspective of the compiler, they're about as different as targeting different OSs.
On Oct 27, 2017, at 5:06 AM, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
Yeah, but by extension, every since compile-time flag is also an “axis of configuration”. What makes these few worthy of special language integration and compiler support?