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

[Leonardo Pessoa]

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 at 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 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> 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
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
> _______________________________________________
> 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/20160514/74c2c659/attachment.html>