> On Mar 14, 2016, at 3:03 PM, Dmitri Gribenko via swift-evolution
> <[email protected]> wrote:
>
> On Mon, Mar 14, 2016 at 2:23 PM, Erica Sadun <[email protected]
> <mailto:[email protected]>> wrote:
>>
>>> On Mar 14, 2016, at 3:12 PM, Dmitri Gribenko <[email protected]> wrote:
>>>
>>> On Mon, Mar 14, 2016 at 1:41 PM, Erica Sadun <[email protected]> wrote:
>>>>
>>>>> On Mar 14, 2016, at 1:55 PM, Dmitri Gribenko <[email protected]> wrote:
>>>>>
>>>>> On Mon, Mar 14, 2016 at 11:48 AM, Erica Sadun via swift-evolution
>>>>> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
