[swift-evolution] [META] Re-invigorating the compiler directive discussion

[Joe Groff]

> On Mar 14, 2016, at 3:03 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Mon, Mar 14, 2016 at 2:23 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>> 
>>> On Mar 14, 2016, at 3:12 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> On Mon, Mar 14, 2016 at 1:41 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>>> 
>>>>> On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>>>> 
>>>>> On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution
>>>>> <swift-evolution at 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? https://gist.github.com/erica/103b5cd17bde4171ae0b
>>> 
>>> 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: https://gist.github.com/erica/b7f4226b8201945602f2
>> * testing sim/device for camera/keychain: https://gist.github.com/erica/6c3892fe603659b6e5ab
>> * testing debug (yes, in methods is just peachy fine for me) for better logging mostly: https://gist.github.com/erica/d20639b409fe1b318c0e
>> 
>> Things I'm doing as a courtesy for the community that I probably will never use:
>> 
>> * testing platform conditions: https://gist.github.com/erica/5a344b12bd989f6395c2
> 
> 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:  https://gist.github.com/erica/103b5cd17bde4171ae0b <https://gist.github.com/erica/103b5cd17bde4171ae0b>
>> 
>> -- 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.

Even in a unified libc module world, I think it would make sense to separate 'libc' for the standard C APIs from the OS platform's 'POSIX' or 'Win32' modules (and maybe Glibc/Darwin/Musl/MSVCRT/Mingw/Cygwin beyond that for nonstandard CRT-specific APIs). That would let you still get some leverage out of the module-availability-based approach.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160314/588dc6ff/attachment.html>