[swift-evolution] Rewrite imported C function signatures

[Goffredo Marocchi]

+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 <swift-evolution at swift.org> 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 <brent at architechies.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution