> On May 13, 2016, at 12:12 AM, Patrick Pijnappel via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> For some protocols we'd like to require top-level (free) functions, e.g. for 
> many math functions such as abs() or sin(). We already do this implicitly for 
> operators. 

Hi Patrick,

FYI, we’re very likely to remove this special behavior for operators, by making 
operator requirements only find operators declared in a conforming type.  This 
would eliminate the special case for operators that exists now, and has other 
advantages as well.  Check out this proposal for more information:
https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md

-Chris

> 
> Proposal
> Allow top-level function/property requirements in protocols, e.g.:
> 
> public protocol AbsoluteValuable : SignedNumber {
>   /// Returns the absolute value of `x`.
>   @warn_unused_result
>   toplevel func abs(_ x: Self) -> Self
> }
> 
> We'd probably want to require this for operators. This also opens up syntax 
> if we ever get dynamically dispatched operators.
> 
> public protocol SignedNumber : Comparable, IntegerLiteralConvertible {
>   /// Returns the result of negating `x`.
>   @warn_unused_result
>   toplevel prefix func - (x: Self) -> Self
> }
> 
> Currently this is done using the combination of a static method and a 
> top-level generic function on that protocol. As I understand that approach 
> does have some benefits in terms of type-checker performance, though I'm not 
> sure whether that is likely to stay relevant in the future.
> 
> Advantages
> Cleaner than current approach (esp. floating point types have tons of 
> top-level functions)
> Makes operators less of a special case
> Opens up syntax for member operators
> Could also apply to top-level properties (esp. useful if we get generic 
> properties, for e.g. π<...>)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to