[SR-4172] () == () doesn't compile

[lilyball]

Previous ID	SR-4172
Radar	None
Original Reporter	@lilyball
Type	Bug
Status	Resolved
Resolution	Done

Environment

Apple Swift version 3.0.2 (swiftlang-800.0.63 clang-800.0.42.1)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug
Assignee	anayini (JIRA)
Priority	Medium

md5: b7c81b111f008dc786f236ab4d1c0698

Issue Description:

As the summary says, () == () doesn't compile. This seems like an oversight, since tuples (up to 6-ary) support == if they can (i.e. if all their elements are Equatable), and there's no reason why the base case of the 0-ary tuple shouldn't.

[swift-ci]

Comment by Arjun Nayini (JIRA)

Eridius (JIRA User) - Brand new to the Swift project and saw this bug as potentially a good task. Was thinking about adding a generated 0-ary `==` implementation to resolve this problem. Seems to work fine in a Playground. Can I self-assign this and complete it or is there typically an approval process where this is marked as a bug by the core team before someone can self-assign.

[lilyball]

anayini (JIRA User) There's no official approval process for bug tickets. You should be able to self-assign and submit a PR.

[airspeedswift]

What's the use case for this? If it's highly marginal/just for consistency, it may not be worth increasing the size of the std lib just for this case, whereas it's fine if there's a way in which this neatens up some likely code.

[swift-ci]

Comment by Arjun Nayini (JIRA)

@airspeedswift - I'm not the reporter, just grabbed the ticket since it seemed like an easy starter task to be honest. I agree that, especially after adding the `Comparable` operators, which I guess were out of scope of this bug, the diff has become sort of large.

[airspeedswift]

Hi Arjun – thanks so much for picking this up! It's definitely appreciated, whether or not we end up deciding to integrate.

[lilyball]

Why would you add comparable operators for ()? It doesn't make much sense to say () < (). As for stdlib size, each operator is a single really tiny function with no generics, so the size difference should be pretty tiny.

[swift-ci]

Comment by Arjun Nayini (JIRA)

Eridius (JIRA User) - Original PR I put up actually only added `==`, but sounds like people wanted the rest of the operators as well. Maybe at least `==` and `!=` make sense?

If we can agree that the `Comparable` operators don't make sense, the PR becomes a small addition to the file (1 or 2 functions depending on if we want to include `!=`)

[lilyball]

In any case, the code that motivated this ticket looked like

#if os(iOS) || os(OSX) || os(watchOS) || os(tvOS)
    import struct Foundation.Decimal
#else
    // A placeholder used for platforms that don't support `Decimal`.
    public typealias DecimalPlaceholder = ()
#endif

public enum Foo {
    // ...
    #if os(iOS) || os(OSX) || os(watchOS) || os(tvOS)
    case decimal(Decimal)
    #else
    // A plceholder for decimal number support.
    // We need this or else people can't write exhaustive switches against our
    // enum in a cross-platform-compatible way.
    case decimal(DecimalPlaceholder)
    #endif

    public static func ==(lhs: Foo, rhs: Foo) -> Bool {
        switch (lhs, rhs) {
        // ...
        case let (.decimal(a), .decimal(b)): return a == b
        }
    }
}

But of course this doesn't actually compile on Linux because () doesn't support equality.

[lilyball]

anayini (JIRA User) I only care about == and !=. I don't think it makes a whole lot of sense to implement the other comparison operators, but I'm not particularly opposed to it if other people want them.

[lilyball]

Also, if you have a PR, can you please link it here?

[swift-ci]

Comment by Arjun Nayini (JIRA)

Ah yup - sorry - here it is:
#8354

[swift-ci]

Comment by Arjun Nayini (JIRA)

Fixed in #8354

[swift-ci]

Comment by Arjun Nayini (JIRA)

Eridius (JIRA User) - This finally got in 🙂