>> What's wrong with just overloading it like this without hiding the original?
>> That way you can start by directly porting (perhaps even mechanically
>> converting) the code and later refine it to use the nicer Swift-style
>> overload.
>
> Well, the difference is that the compiler could produce a warning or error
> with fixit to indicate the developer that an alternative signature to the
> originally C imported one is available. This way, code ports should gain much
> readability, while not requiring much effort from the developer to make use
> of the newer signature.
If that's all you want, maybe we can have an attribute which says "prefer this
version over that one":
@preferred(since: 3.0, over: socket(_: Int32, _: Int32, _: Int32) ->
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
}
}
This would effectively apply an `@available(deprecated: 3.0, renamed:
socket(domain: SocketDomain, type: SocketType, protocol: SocketProtocol) ->
socket_t?)` to the other API.
(Or, for that matter, you could simply use an API note to apply that
deprecation to the other API, which would not require any new features.)
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
