Separate operators from functions

[kareman]

Even though Swift operators are technically functions I think it would be useful to at least optionally list operators under their own heading. Especially in this case where there is a function $ which now looks like an operator.

[jpsim]

Thanks for the feature request! I don't know if it's possible for us to do, but we'll keep this open to track it anyway.

[nickplee]

+1

[p2]

Would be great to have! One of my documentations “Other Functions” section currently looks like this:

<(_:_:)
<(_:_:)
<(_:_:)
<(_:_:)
<(_:_:)
==(_:_:)
==(_:_:)
==(_:_:)
==(_:_:)
==(_:_:)
==(_:_:)

[jpsim]

Just curious, how do you all think this should be handled in the generated HTML?

I totally agree it's not very useful to have a bunch of ==(_:_:) functions.

Maybe an Operator Functions category that uses the declaration instead of the name? For Realm Swift, it would look like this:

==(lhs: ErrorType, rhs: ErrorType) -> Bool
==(lhs: ObjectSchema, rhs: ObjectSchema) -> Bool
==(lhs: Property, rhs: Property) -> Bool
==(lhs: Realm, rhs: Realm) -> Bool
==(lhs: Schema, rhs: Schema) -> Bool
==(lhs: SortDescriptor, rhs: SortDescriptor) -> Bool

Here's an entirely different idea of how it could be displayed:

ErrorType == ErrorType
ObjectSchema == ObjectSchema
Property == Property
Realm == Realm
Schema == Schema
SortDescriptor == SortDescriptor

Implementation aside, how would this ideally work for you?

[segiddins]

Another option would be to list each operator once, and on that operators page have each implementation

[jpsim]

ooh, I like that idea

[kareman]

Yes I think I would prefer listing each operator once too. Less clutter in the menu.

[nickplee]

Thumbs up to all of this.

Sent from my iPhone

On Jun 9, 2016, at 9:06 PM, Kare Morstol [email protected] wrote:

Yes I think I would prefer listing each operator once too. Less clutter in the menu.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[segiddins]

[segiddins]

This is also an option:

[p2]

I'd not need the operators listed in the menu, just appear on the page of the type definition. So whenever I look at the type, I se that it conforms to Equatable and co.

[segiddins]

@p2 the trouble with that is that operators (and functions in general) don't 'belong' to any type

[p2]

Sure, and probably only few add an empty extension Type: Equatable { } before the definition. Still, it's what I'd like to look my docs like. :)

[p2]

FWIW, Xcode 8b5 now allows to move these into the type bodies, wohoo!

public struct Foo: Equatable {
    var value: String
    public static func ==(lhs: Foo, rhs: Foo) -> Bool {
        return lhs.value == rhs.value
    }
}

[karagraysen]

I believe this issue has been resolved as per @p2's last comment. Feel free to re-open if there's more to be done that I missed. Still getting familiar with the project. :)

[jpsim]

No, I think @p2's excitement was more for the language feature than what this ticket is tracking.

[karagraysen]

I realized that afterwards. My apologies - sounds good though.

[reitzig]

FWIW, there is some overlap with #787 here regarding how to display operators. For non-symmetric operators like, say, <=(lhs: Int, rhs: Int/Double/...) the default <=(_:_:) is still not helpful. (As in, even if all operators are declared in their "mother" types as opposed to at the top level).