Re: [swift-evolution] [draft] Target environment platform condition

> On Oct 27, 2017, at 5:06 AM, Karl Wagner via swift-evolution > 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? The "environment" field is an optional

Re: [swift-evolution] [draft] Target environment platform condition

> On 26. Oct 2017, at 17:13, Dave DeLong via swift-evolution > wrote: > > >> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> it’s not like I don’t understand when you’d want some different behaviour in >> a program to account

Re: [swift-evolution] [draft] Target environment platform condition

> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution > wrote: > > 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 feel

Re: [swift-evolution] [draft] Target environment platform condition

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, CP

Re: [swift-evolution] [draft] Target environment platform condition

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 devic

Re: [swift-evolution] [draft] Target environment platform condition

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/em

Re: [swift-evolution] [draft] Target environment platform condition

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 nota

Re: [swift-evolution] [draft] Target environment platform condition

Could this be an extra parameter for the os() platform condition? #if os(iOS, simulator) #if os(Android, emulator) -- Ben > On 25 Oct 2017, at 04:05, Graydon Hoare wrote: > > Hi, > > I'd like to propose a variant of a very minor, additive proposal Erica Sadun > posted last year, that cleans

Re: [swift-evolution] [draft] Target environment platform condition

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 li

Re: [swift-evolution] [draft] Target environment platform condition

One quick question... WRT `os()`, should that take a string instead of some keywordish thing? There's at least one OS which has a Swift port, but doesn't show up on that list (Haiku: https://www.haiku-os.org/blog/return0e/2017-08-28_gsoc_2017_porting_swift_to_haiku_-_final_report/

Re: [swift-evolution] [draft] Target environment platform condition

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, th

[swift-evolution] [draft] Target environment platform condition

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