Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
lilyball mannequin opened this issue Mar 6, 2017 · 13 comments
Closed

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

lilyball mannequin opened this issue Mar 6, 2017 · 13 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@lilyball
Copy link
Mannequin

lilyball mannequin commented Mar 6, 2017

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
Copy link
Collaborator

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
Copy link
Mannequin Author

lilyball mannequin commented Mar 23, 2017

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

@airspeedswift
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Member

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

@lilyball
Copy link
Mannequin Author

lilyball mannequin commented Mar 28, 2017

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
Copy link
Collaborator

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
Copy link
Mannequin Author

lilyball mannequin commented Mar 28, 2017

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
Copy link
Mannequin Author

lilyball mannequin commented Mar 28, 2017

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
Copy link
Mannequin Author

lilyball mannequin commented Mar 28, 2017

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

@swift-ci
Copy link
Collaborator

Comment by Arjun Nayini (JIRA)

Ah yup - sorry - here it is:
#8354

@swift-ci
Copy link
Collaborator

Comment by Arjun Nayini (JIRA)

Fixed in #8354

@swift-ci
Copy link
Collaborator

Comment by Arjun Nayini (JIRA)

Eridius (JIRA User) - This finally got in 🙂

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

2 participants