[swift-evolution] [Pitch] Add toplevel keyword for protocols

[Patrick Pijnappel]

>
> 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 <clattner at apple.com> wrote:

>
> On May 13, 2016, at 12:12 AM, Patrick Pijnappel via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/ced49c18/attachment.html>