[swift-evolution] Rewrite imported C function signatures

Carlos Rodríguez Domínguez carlos at everywaretech.es
Fri Mar 25 05:25:25 CDT 2016


(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.



More information about the swift-evolution mailing list