<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="margin: 0px;">Thanks for using specific examples, as they are illustrative.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;"><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;">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.</blockquote></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">exit is an interesting case. Believe it or not, it is *not* portable, as used here. The C standard defines two constants for its parameter: EXIT_SUCCESS (defined to be zero) and EXIT_FAILURE (undefined). You can pass other values (trivia time: only values less than 0377, because the high bits of this integer are reserved on some platforms), but the "fail-iarity" or "successiness" of values other than the defined two are not specified and may take on different meanings on different platforms. C programmers commonly pick a nonzero value to indicate failure (as I did here) – sometimes multiple distinct values to indicate different kinds of failure – but this is actually non-portable.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">The reason I am being pedantic here is because it demonstrates a broader point: people do not actually write portable code; they target either their current platform or some vague amalgamation of 2-3 platforms in their immediate vicinity. All the platforms I cared about do something sane with exit(1) so it's "portable enough". But "portable enough" isn't portable.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="margin: 0px;"><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;"> In any case, the four lines at the top of your files are almost certainly inconsistent on other platforms; for example, do you test for freebsd? Or ps4?</blockquote></div> <br> <div id="bloop_sign_1479230095688573952" class="bloop_sign">This is a feature, not a bug. We *like* compiler errors because they give us early warning we got something wrong.</div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><br></div><div id="bloop_sign_1479230095688573952" class="bloop_sign">I *want* the compiler to stop me when compiling this for OpenVMS. When I wrote this code, I had only Darwin/Glibc in mind, and on that basis, I used exit(1). The working assumption is now violated, and the compiler is correct to remind me about it. I don't know, and would need to go find out, what kind of exit is sensible for VMS. Or to move to EXIT_FAILURE like a language lawyer.</div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><br></div><div id="bloop_sign_1479230095688573952" class="bloop_sign">But the compile error itself is not a silly annoyance that I would like to "solve" by blindly putting more libcs in the list etc. This is a guard rail where I indicated the platforms I had in mind when writing this code, and when I wake up one morning in a drunken stupor and try to do something else, we fire a warning shot.</div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><br></div><div id="bloop_sign_1479230095688573952" class="bloop_sign">It's a safety feature, like force-unwrap. If you're sure it won't blow up, you can put an exclamation mark in there and shut up the compiler. If you're sure it's portable to bsd, add bsd to the list and shut up the compiler. But the resolution to this compile error is not to import more libcs. The resolution is to *consider carefully if that is a good idea*.</div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><br></div><div id="bloop_sign_1479230095688573952" class="bloop_sign">The assumption embedded in the proposal is that of course we want the program to compile, and the question is merely to calculate the set of import statements that will achieve compilation, for which the proposal offers an algorithm. My argument is that actually we do not want the program to compile unless we are reasonably sure it will work as intended, and the question is what syntax allows the author to reasonably encode their assumptions so that when they are violated we provide a moment of quiet reflection to consider e.g. if exit(1) is sensible on VMS.</div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><br></div><div id="bloop_sign_1479230095688573952" class="bloop_sign">The existing system is imperfect (and very ugly) but does a surprisingly good job in this dimension.</div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><br></div><div id="bloop_sign_1479230095688573952" class="bloop_sign"><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""> It also doesn't seem to support some of the other platforms that might be desirable in a test framework, such as iOS, watchOS or tvOS.</div></div></blockquote></div><p>I do support iOS (not in this component – it's a command-line tool, so the omission of iOS in this file is deliberate, and the compatibility issues go far beyond exit). I don't yet support watchOS or tvOS because I don't have CI for those platforms yet and in my view supporting a platform is more than adjusting an import statement and wondering if it will compile.</p><p>So in summary:</p><p>1. I would not use this feature in the cited examples</p><p>2. I would prefer it if others did not use this feature. When I see "import Glibc" at the top of a file I know what I am signing up for. When I see "import libc" for all I know the developer used Windows.</p><p>Finally, this is more of a detail, but I still do not understand how this would be implemented for a Linux platform without Glibc, such as Arch. The current proposal has </p><p><br></p><div><blockquote type="cite" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;"><p> #if os(Linux)</p><p> @_exported import Glibc</p></blockquote></div><p>which is obviously not going to compile on Arch. So if the goal is to have syntax that is portable the current proposal does not do it.</p><p>I do believe there is some room for a more moderate reform on the libc problem. For example instead of the traditional ifdefs, we could have</p><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;"><p>import? Glibc</p><p>import? Darwin</p></blockquote><div><br class="Apple-interchange-newline"></div><div>Where the "import?" keyword imports the module if available or otherwise has no effect.</div><div><br></div><div>This preserves the majority of desireable properties discussed above (clearly indicates the intended libcs, provides guard rails similar to the present regime) while being significantly shorter than the present regime. It also contemplates problems that the current proposal does not, such as Arch (we can continue to list libcs until we find one, and Swift already has rules for resolving multiple imports), and it is more broadly applicable to other kinds of import problems than libc imports narrowly.</div><div><br></div><div>One problem with the import? idea is that it glosses e.g. watchOS/tvOS/macOS as "Darwin" when that is not strictly true (posix_spawn for example) but it's at least a far more sensible unification than VMS/Darwin. We do have a clear path to check Darwin portability in the compiler (e.g. require @availability(macOS) for posix_spawn) while no similar path exists to check Darwin/VMS portability. So I think doing something moderate is at least plausible.</div><div><br></div><div>Still, it may be a solution in search of a problem. If you are writing against something as badly fractured as POSIX, it should feel like it, and even a small unification may be a step too far.</div><div><br></div><div>Of course, the real solution to writing portable code is to target a portable standard, such as Foundation or some alternative high-level library.</div></div><p class="airmail_on">On November 15, 2016 at 10:27:14 AM, Alex Blewitt (<a href="mailto:alblue@apple.com">alblue@apple.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title class=""></title>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 11 Nov 2016, at 03:48, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div class=""> grep -R "import Glibc" ~/Code --include
"*.swift" | wc -l<br class=""></div>
<div class=""> 297</div>
<div class=""><br class=""></div>
<div class="">As someone who might be characterized as suffering
from the problem this proposal purports to solve, I am not
convinced.<br class=""></div>
<div class=""><br class=""></div>
<div class="">The primary problem here is that "libc" is a
misnomer. Did you mean musl, dietlibc, or glibc? Did
you mean "whatever libc my distro likes?" Swift in practice
only supports one per platform, but that is a bug not a feature,
and that bug should not be standardized. We could try to
invent some syntax to specify one but now we are back with the
current system again.<br class=""></div>
</div>
</div>
</blockquote>
<div><br class=""></div>
<div>We're at the current system to start off with, though. When
you do "import Darwin" or "import GlibC" you're getting whatever
the platform has, regardless of what you call it. You could call it
something else, like "Platform" or "Base" but it doesn't change the
suggestion itself.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="">The other problem is that in all my usages, "import
Glibc" is not a real problem I face. The real problems are
that "the libcs <i class="">plural</i>" are *just different*.
Darwin has timeval64, glibc does not, and you'd better check
your arch and pick the right one, only on one platform.
SO_REUSEADDR has one type in Brand X and another type in
Brand Y. Don't even get me *started* on poll, EREs, or half a
dozen other behavioral variations. </div>
</div>
</div>
</blockquote>
<div><br class=""></div>
<div>Yes, these are issues. Some of them will be worked out with
the swift server workgroup, or at least standardising Socket as a
type which abstracts the platform away. But we're at that position
at the moment, whether or not there's a standard module to
represent Darwin/Glibc.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<div class="">Taking two different libraries and pretending they
are the same is not the solution, it's the disease. The way
out of this swamp for most developers is to use a real Swift
library, the same damn Swift library, on all platforms (sadly,
Foundation today does not meet this requirement). The way out
of this swamp for crazy people like me who must write to the metal
is to actually write to the metal, to the particular libc being
targeted, not to a hypothetical platonic ideal libc which does not
exist. </div>
<div class=""><br class=""></div>
<div class="">I realize that four lines at the top of my files is a
*visible* annoyance, but fixing it just promotes it to an invisible
one. <br class=""></div>
</div>
</div>
</blockquote>
<div><br class=""></div>
</div>
Not necessarily, it can be a starting point to fix some of the
other problems. In any case, the four lines at the top of your
files are almost certainly inconsistent on other platforms; for
example, do you test for freebsd? Or ps4?
<div class=""><br class=""></div>
<div class=""><a href="https://github.com/drewcrawford/Caroline/blob/26cd0d71e57a62fac6258e4e13dfd6849a1945c6/caroline-static-tool/FileUtils.swift" class="">https://github.com/drewcrawford/Caroline/blob/26cd0d71e57a62fac6258e4e13dfd6849a1945c6/caroline-static-tool/FileUtils.swift</a></div>
<div class="">
<table class="js-file-line-container highlight tab-size" data-tab-size="8" style="box-sizing: border-box; border-spacing: 0px; border-collapse: collapse; tab-size: 8; color: rgb(51, 51, 51); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 14.000000953674316px;">
<tbody style="box-sizing: border-box;" class="">
<tr style="box-sizing: border-box;" class="">
<td id="LC13" class="js-file-line blob-code-inner blob-code" style="box-sizing: border-box; padding: 0px 10px; position: relative; line-height: 20px; vertical-align: top; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; word-wrap: normal; white-space: pre;">
<br class=""></td>
</tr>
<tr style="box-sizing: border-box;" class="">
<td id="L15" class="blob-num js-line-number" data-line-number="15" style="box-sizing: border-box; padding: 0px 10px; width: 50px; min-width: 50px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; line-height: 20px; color: rgba(0, 0, 0, 0.298039); text-align: right; white-space: nowrap; vertical-align: top; cursor: pointer; -webkit-user-select: none; border-style: solid; border-color: rgb(238, 238, 238); border-width: 0px 1px 0px 0px;">
<br class=""></td>
<td id="LC15" class="js-file-line blob-code-inner blob-code" style="box-sizing: border-box; padding: 0px 10px; position: relative; line-height: 20px; vertical-align: top; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; word-wrap: normal; white-space: pre;">
#<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">if</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">os</span>(<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">OSX</span>)</td>
</tr>
<tr style="box-sizing: border-box;" class="">
<td id="L16" class="blob-num js-line-number" data-line-number="16" style="box-sizing: border-box; padding: 0px 10px; width: 50px; min-width: 50px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; line-height: 20px; color: rgba(0, 0, 0, 0.298039); text-align: right; white-space: nowrap; vertical-align: top; cursor: pointer; -webkit-user-select: none; border-style: solid; border-color: rgb(238, 238, 238); border-width: 0px 1px 0px 0px;">
</td>
<td id="LC16" class="js-file-line blob-code-inner blob-code" style="box-sizing: border-box; padding: 0px 10px; position: relative; line-height: 20px; vertical-align: top; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; word-wrap: normal; white-space: pre;">
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">import</span>
<span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">Darwin</span></td>
</tr>
<tr style="box-sizing: border-box;" class="">
<td id="L17" class="blob-num js-line-number" data-line-number="17" style="box-sizing: border-box; padding: 0px 10px; width: 50px; min-width: 50px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; line-height: 20px; color: rgba(0, 0, 0, 0.298039); text-align: right; white-space: nowrap; vertical-align: top; cursor: pointer; -webkit-user-select: none; border-style: solid; border-color: rgb(238, 238, 238); border-width: 0px 1px 0px 0px;">
</td>
<td id="LC17" class="js-file-line blob-code-inner blob-code" style="box-sizing: border-box; padding: 0px 10px; position: relative; line-height: 20px; vertical-align: top; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; word-wrap: normal; white-space: pre;">
#<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">elseif</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">os</span>(<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Linux</span>)</td>
</tr>
<tr style="box-sizing: border-box;" class="">
<td id="L18" class="blob-num js-line-number" data-line-number="18" style="box-sizing: border-box; padding: 0px 10px; width: 50px; min-width: 50px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; line-height: 20px; color: rgba(0, 0, 0, 0.298039); text-align: right; white-space: nowrap; vertical-align: top; cursor: pointer; -webkit-user-select: none; border-style: solid; border-color: rgb(238, 238, 238); border-width: 0px 1px 0px 0px;">
</td>
<td id="LC18" class="js-file-line blob-code-inner blob-code" style="box-sizing: border-box; padding: 0px 10px; position: relative; line-height: 20px; vertical-align: top; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; word-wrap: normal; white-space: pre;">
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">import</span>
<span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">Glibc</span></td>
</tr>
<tr style="box-sizing: border-box;" class="">
<td id="L19" class="blob-num js-line-number" data-line-number="19" style="box-sizing: border-box; padding: 0px 10px; width: 50px; min-width: 50px; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; line-height: 20px; color: rgba(0, 0, 0, 0.298039); text-align: right; white-space: nowrap; vertical-align: top; cursor: pointer; -webkit-user-select: none; border-style: solid; border-color: rgb(238, 238, 238); border-width: 0px 1px 0px 0px;">
</td>
<td id="LC19" class="js-file-line blob-code-inner blob-code" style="box-sizing: border-box; padding: 0px 10px; position: relative; line-height: 20px; vertical-align: top; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; word-wrap: normal; white-space: pre;">
#<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">endif</span></td>
</tr>
</tbody>
</table>
<div class=""><br class=""></div>
</div>
<div class="">So your test framework doesn't work on FreeBSD by
default. Yet they've still got the same 'write' method. It also
doesn't seem to support some of the other platforms that might be
desirable in a test framework, such as iOS, watchOS or tvOS. You'll
just get silent errors on those when it's used on those platforms.
And as new platforms get added, your code will slowly drift further
away from supporting everything to supporting a few known
values.</div>
<div class=""><br class=""></div>
<div class="">Now granted, some of these may have yet more
incompatible versions for 'write' which needs handling
specifically. That's bad, and it should be something that can be
worked on. But most of the other functions (like 'close') don't
need handling specifically. Or, as used in <a href="https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift" class="">https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift</a> to
just get access to the exit() function, which is the same across
all platforms.</div>
<div class=""><br class=""></div>
<div class="">Other proposals - such as Johannes' treatment of how
to handle errno - will help work around these problems. Perhaps we
end up with a generic write function that wraps the platform
specific one to abstract that away as well, which reduces these
issues one by one.</div>
<div class=""><br class=""></div>
<div class="">Alex</div>
</div></div></span></blockquote></body></html>