<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 6:40 AM, Perry E. Metzger via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: 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-stroke-width: 0px; float: none; display: inline !important;" class="">This will also require a bit of design to look "Swifty”.</span></div></blockquote><br class=""></div><div>Yes, amen. The thought of a Swift bridge to the standard C library gives me queasy thoughts of PHP, whose core APIs are a horrible pidgin translation of C.</div><div><br class=""></div><div>An I/O library should begin with an abstract stream API, which can then be given a concrete file-descriptor-based implementation that can be used for files, sockets, etc. (Although the fact that it’s based on file descriptors should be hidden.)</div><div><br class=""></div><div>IMHO one of the biggest design problems of Foundation is that it has very weak support for streams. NSStream is very difficult to subclass, and most I/O doesn’t even use it, so there are historical remnants like NSFileHandle and high-level alternatives like -[NSData initWithContentsOfFile:] that everyone ends up using.</div><div><br class=""></div><div><blockquote type="cite" class=""><span style="font-family: Alegreya-Regular;" class="">A lower layer is also needed -- simple Swifty wrappers for the Unix</span><br style="font-family: Alegreya-Regular;" class=""><span style="font-family: Alegreya-Regular;" class="">system calls so that Swift implementations can get at them without</span><br style="font-family: Alegreya-Regular;" class=""><span style="font-family: Alegreya-Regular;" class="">having to use unsafe constructs. open(2), read(2), write(2), lseek(2)</span><br style="font-family: Alegreya-Regular;" class=""><span style="font-family: Alegreya-Regular;" class="">and close(2) would provide about 75% of what one needs for the higher</span><br style="font-family: Alegreya-Regular;" class=""><span style="font-family: Alegreya-Regular;" class="">layer stuff (and everything one would want for stdio) with quite</span><br style="font-family: Alegreya-Regular;" class=""><span style="font-family: Alegreya-Regular;" class="">minimal hacking.</span></blockquote><br class=""></div><div>I agree, but I foresee problems in the future when Swift is ported to Windows. :/</div><div><br class=""></div><div>—Jens</div></body></html>