[swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

[Joe Groff]

> On Nov 4, 2016, at 9:12 AM, Johannes Weiß <johannesweiss at apple.com> wrote:
> 
> Hi Joe,
> 
>>> I just realised, that the problem is slightly worse than I originally described. I believed that successful calls in between the actual call the programmer wanted to make and capturing `errno` are not a problem.
>>> 
>>> But POSIX seems to suggest [4] that "The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified." . The Linux man page [5] also mentions that "a function that succeeds is allowed to change errno."
>>> 
>>> To me this means that the issue is wider than just ARC. I think the problem extends to memory allocations on the heap. Failed memory allocations aren't a problem because they are terminal in Swift. However, _successful_ memory allocations might be a problem because the malloc(3) that the Swift compiler will use is absolutely free to set errno to 0 (or any other value in fact) indicating success. (Said that at least malloc doesn't change `errno` on the macOS or Linux I tested today, we probably shouldn't rely on that though.)
>>> 
>>> This makes it even more unpredictable to the programmer what a use of `errno` in Swift will return. IMHO it shouldn't be exported to Swift as its value is undefined almost(?) everywhere.
>>> 
>>> [4]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html
>>> [5]: http://man7.org/linux/man-pages/man3/errno.3.html
>> 
>> Swift's implicit allocations don't directly use malloc/free.
> 
> Ah right, that's good to know. But still, "explicit" allocation by creating an object does, right?
> 
> Like
> 
> class Foo {}
> let x = Foo()
> 
> does allocate through _swift_allocObject_ -> swift_slowAlloc -> malloc .

swift_slowAlloc does not need to be implemented by calling malloc.

-Joe