> On Mar 25, 2016, at 3:25 AM, Carlos Rodríguez Domínguez via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
