[swift-users] Pure Swift, cross platform way to open, read/write files?

[Perry E. Metzger]

On Tue, 8 Dec 2015 21:09:33 -0800 Chris Lattner via swift-users
<swift-users at swift.org> wrote:
> 
> > On Dec 8, 2015, at 8:55 PM, Brent Royal-Gordon via swift-users
> > <swift-users at swift.org> wrote:
> > 
> >> But at the same time I get your point just use #if #else #endif
> >> to conditional import / call functions... but coding like that
> >> doesn't seem vary fun... reminds me of looking a C code that was
> >> meant to be compiled on different processor architectures. :-( 
> > 
> > I would really like to see Swift offer a "POSIX" or "LibC" module
> > which would import whatever the current platform offered for a C
> > library. Obviously there would be differences between Glibc and
> > Darwin.C, and I wouldn't expect Swift to try to paper those over,
> > but this `#if os` dance in every file is kind of ridiculous.
> 
> +1

Going through the SUX (http://www.unix.org/online.html ) and reading
the available APIs will probably be inspirational for what's needed
for a POSIX module, and all sorts of things like sockets with a Swifty
flavor are probably needed in the short term, but a good start would
just be a Swifty version of stdio.

I recommend re-implementing stdio in pure Swift rather than just
wrapping the C library. This will make the swift code immune to safety
bugs in an underlying C implementation, and translating the existing
open source BSD stdio will not be onerous.

This will also require a bit of design to look "Swifty". An IO
interface, for example, so that IO to various kinds of things can all
inherit a common API would be useful. (Imagine, later on, being able
to do things like pushing a TLS library on top of an underlying
socket and having the interface remain entirely clean and unchanged.)

A lower layer is also needed -- simple Swifty wrappers for the Unix
system calls so that Swift implementations can get at them without
having to use unsafe constructs. open(2), read(2), write(2), lseek(2)
and close(2) would provide about 75% of what one needs for the higher
layer stuff (and everything one would want for stdio) with quite
minimal hacking.

Perry
-- 
Perry E. Metzger		perry at piermont.com