> On 11 Nov 2016, at 03:48, Drew Crawford <d...@sealedabstract.com> 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 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.
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. > 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 plural" 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. 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. > 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. > > 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. 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? https://github.com/drewcrawford/Caroline/blob/26cd0d71e57a62fac6258e4e13dfd6849a1945c6/caroline-static-tool/FileUtils.swift <https://github.com/drewcrawford/Caroline/blob/26cd0d71e57a62fac6258e4e13dfd6849a1945c6/caroline-static-tool/FileUtils.swift> #if os(OSX) import Darwin #elseif os(Linux) import Glibc #endif 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. 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 https://github.com/drewcrawford/Caroline/blob/edd8aefef44717ecfa03c629100baf095fab983a/caroline-static-tool/main.swift <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. 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. Alex
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
