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

[Patrick Pijnappel]

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 at 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 at swift.org
> <javascript:_e(%7B%7D,'cvml','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.
>>
>> *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
>> <javascript:_e(%7B%7D,'cvml','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/20160514/3d5e9697/attachment.html>