Operators will overload the function with new arguments. That's why I suggested this change in syntax only for operators and force them to have the first argument or the type Self.
- Leonardo On 14 May 2016 at 03:39, Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > Hmm good point. Defining a toplevel function or property could reserve > that name in toplevel scope, but you'd be in trouble when two protocols > from different modules require a toplevel function or property with the > same signature. > > I'm not sure how operators deal with this because they should have the > same problem... > > On Friday, 13 May 2016, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org> wrote: > >> To me this makes more sense for operators than for other functions or >> properties. For the former you could create conflict with previously >> declared function (or properties with variables) and there is no >> restriction in Swift that says you cannot or should not create a top level >> function or property. >> >> In this sense, having an operator declared inside a class/struct/enum >> would already make them top level as you proposed, no need for another >> keyword. I would only add one requirement: that the first argument should >> always be of type Self (and have it checked by the compiler). It ensures >> the operator operates on that type and helps minimising conflicts with a >> previously declared operator. >> >> - Leonardo >> >> On 13 May 2016 at 04:12, 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. >>> >>> *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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution