[swift-evolution] Rewrite imported C function signatures

[Douglas Gregor]

> On Mar 25, 2016, at 3:25 AM, Carlos Rodríguez Domínguez via swift-evolution <swift-evolution at swift.org> wrote:
> 
> (Please, take a look at the proposal named "[swift-evolution] Promote "primitive" types to enums in extensions” in order to understand the intention of my proposal as a whole)
> 
> This proposal intends to allow developers to rewrite func signatures to better adapt certain imported C functions to swift. For instance, the function to create a POSIX socket has a C signature like this:
> 
> int socket(int domain, int type, int protocol);
> 
> In swift, it is currently imported like this:
> 
> func socket(_: Int32, _: Int32, _: Int32) -> Int32
> 
> However, by documentation, the first parameter should be one of a set of constants beginning with PF_. The second one should be either SOCK_STREAM, SOCK_DGRAM or SOCK_RAW. The third one should be a constant specifying the protocol to use. Finally, the result could be either -1 (to indicate an error) or another integer to indicate that a socket descriptor has been returned.
> 
> As you can observe, that old-style signature is highly error prone, does not comply with swift guidelines, it is difficult to understand, etc. My opinion is that there should be some syntax to rewrite the signature to avoid those issues. For instance, a possible syntax could be:
> 
> #mapsignature(socket(_:,_:,_:)->Int32)
> func socket(domain:SocketDomain, type:SocketType, protocol:SocketProtocol) -> socket_t? {
> 	let result = socket(domain.rawValue, type.rawValue, protocol.rawValue)
> 	if result == -1 {
> 		return nil
> 	}
> 	else{
> 		return result
> 	}
> }
> 
> Note that the compiler should enforce a function call to the original function that we are rewriting.
> 
> After a rewriting has happened, three options may be considered: either to allow the original function to be called, to avoid the original function to be called (through a compiler error with a fix-it) or to emit a warning, advising the developer to adopt the rewritten signature.
> 
> Anyhow, this proposal should allow a greatly increased interoperability between old style code and swift, which, in my opinion, is quite “forced” right now.

FWIW, there have been a number of proposals in roughly this space, using annotations in the C headers to improve the mapping into Swift, including

	Import as member: https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
	Import Objective-C constants as Swift types: https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md
	Better translation of Objective-C APIs into Swift (the swift_name attribute part, at least): https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md

	- Doug