> > 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
Thanks, hadn't seen that one yet! Looks like a good solution. On Sun, May 15, 2016 at 7:10 AM, Chris Lattner <clatt...@apple.com> wrote: > > 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