+1 for me too, sounds like a very useful syntax with a not incredibly huge cost.
[[iOS messageWithContent:webContent] broadcast] > On 27 Mar 2016, at 09:31, Carlos Rodríguez Domínguez via swift-evolution > <[email protected]> wrote: > > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
