>
> 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
> On May 13, 2016, at 12:12 AM, Patrick Pijnappel via swift-evolution
> 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
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
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
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 {