Proposal to expose fcntl() API as part of the Swift stdlib.

[billabt]

Previously discussed on the Swift Evolution forum.

[gribozavr]

Swift does support va_list functions, it only does not support variadic ones.

[billabt]

I’ll fix the proposal… Thanks.

-Bill

On Dec 7, 2015, at 12:52 PM, Dmitri Gribenko notifications@github.com wrote:

In proposals/fcntl-additions-to-stdlib.md #38 (comment):

@@ -0,0 +1,68 @@
+# Expose fcntl() API as part of the Swift stdlib
+
+* Proposal: [SE-NNNN]
+* Author(s): Bill Abt
+* Status: Review
+* Review manager: TBD
+
+## Introduction
+
+At the present time Swift does not support the calling of variadic / va_list
Swift does support va_list functions, it only does not support variadic ones.

—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-evolution/pull/38/files#r46852344.

[manavgabhawala]

I think this is more of an implementation detail rather than a proposal to change the language. I am sure if you made this change to the swift std lib directly and made a pull request with the changes that they would be accepted even without any talks in swift evolution. I think everyone can agree exposing C functions better to swift is a good thing so there isn't really a need to discuss it in swift evolution.

[gribozavr]

@manavgabhawala Every change to the library API need to go through the evolution process.

[billabt]

@gribozavr I totally agree. There can be side effects and who knows what as a result of adding things to the library without any sort of prior discussion. It doesn’t take long to write up a proposal nor does it do any harm if folks discuss it…

-Bill

On Dec 7, 2015, at 2:28 PM, Dmitri Gribenko notifications@github.com wrote:

@manavgabhawala https://github.com/manavgabhawala Every change to the library API need to go through the evolution process.

—
Reply to this email directly or view it on GitHub #38 (comment).

[ddunbar]

I feel like it might be worth having an exception if the new code just adds Glibc support for the same APIs as we already support on Darwin. That is an important thing to call out on any patch to the overlays, in any case.

[billabt]

In this case, it’s a combination. fcntl() is currently not supported in either Darwin or Glibc. open(), open() and see_open() are already in Darwin but not Glibc. In the PR that I did that contains the implementation (swiftlang/swift#196 swiftlang/swift#196) you’ll see the last three are straight ports from the Darwin implementation. The fcntl() implementation is entirely new and includes a full battery of test cases. So this is basically a hybrid and should probably go thru swift-evolution. Thoughts?

On Dec 10, 2015, at 1:05 PM, Daniel Dunbar notifications@github.com wrote:

I feel like it might be worth having an exception if the new code just adds Glibc support for the same APIs as we already support on Darwin. That is an important thing to call out on any patch to the overlays, in any case.

—
Reply to this email directly or view it on GitHub #38 (comment).

[lattner]

Daniel, I agree with you - there is nothing to design/review on that case, it is simply a parity issue. I'll bring this up with Doug even though it doesn't relate to this specific case.

[DougGregor]

Sorry for the back-and-forth here; I think this can just be handled as a fix to the Darwin and Glibc overlays, because it is working around a compiler limitation (inability to importer variadic C functions) to expose the same API one would get from POSIX.

[lattner]

Bill, I'm sorry for the delay on this - we're all still learning how to do things.

[billabt]

No problem. I completely understand. So am I. Just ask Dmitri. 😃

On Dec 10, 2015, at 8:26 PM, Chris Lattner notifications@github.com wrote:

Bill, I'm sorry for the delay on this - we're all still learning how to do things.

—
Reply to this email directly or view it on GitHub #38 (comment).