That’s a really good syntax. Maybe the new @preferred could complete the current @available, by also providing fix-it support. Note that it should be enforced to have “compatible” parameters and return types between the old-style func and the preferred one, as opposed to the current @available, which does not have this enforcement (thus not providing fix-it support).
> El 26 mar 2016, a las 22:00, Brent Royal-Gordon <[email protected]> > escribió: > >>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
