OpenVMS isn't in the supported list of Swift packages, so comparing it to that
is pointless.
https://github.com/apple/swift/blob/c3b7709a7c4789f1ad7249d357f69509fb8be731/lib/Basic/LangOptions.cpp#L26-L36
static const StringRef SupportedConditionalCompilationOSs[] = {
"OSX",
"tvOS",
Thanks for using specific examples, as they are illustrative.
Or, as used in
https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift
to just get access to the exit() function, which is the same across all
platforms.
exit is an
> On 11 Nov 2016, at 03:48, Drew Crawford wrote:
>
> grep -R "import Glibc" ~/Code --include "*.swift" | wc -l
> 297
>
> As someone who might be characterized as suffering from the problem this
> proposal purports to solve, I am not convinced.
>
> The primary
I agree that trying to completely unify low-level platforms is usually a mess.
That said, I also don’t think accessing platform specific behaviour needs to
involve completely throwing away the nice abstractions in Foundation. Wherever
possible, we should provide platform-specific extensions to
grep -R "import Glibc" ~/Code --include "*.swift" | wc -l
297
As someone who might be characterized as suffering from the problem this
proposal purports to solve, I am not convinced.
The primary problem here is that "libc" is a misnomer. Did you mean
musl, dietlibc, or glibc? Did you
on Wed Nov 09 2016, Matt Wright wrote:
>> On Nov 9, 2016, at 10:58 AM, Alex Blewitt via swift-evolution
>> wrote:
>>
>> Although out of scope for phase 1, something that keeps cropping up
>> in a variety of Linux/Darwin Swift scripts is
> On Nov 9, 2016, at 10:58 AM, Alex Blewitt via swift-evolution
> wrote:
>
> Although out of scope for phase 1, something that keeps cropping up in a
> variety of Linux/Darwin Swift scripts is the conditional inclusion of Darwin
> or GlibC per platform. The last
Although out of scope for phase 1, something that keeps cropping up in a
variety of Linux/Darwin Swift scripts is the conditional inclusion of Darwin or
GlibC per platform. The last point was an observation that creating a 'nice'
wrapper for LibC or a cleaned up POSIX API is a non-goal: