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

Conform to ExpressibleByArrayLiteral and ExpressibleByDictionaryLiteral #49

Merged
merged 7 commits into from
Mar 15, 2022
Merged

Conform to ExpressibleByArrayLiteral and ExpressibleByDictionaryLiteral #49

merged 7 commits into from
Mar 15, 2022

Conversation

fwcd
Copy link
Contributor

@fwcd fwcd commented Mar 15, 2022

Fixes #48

This branch adds experimental support for the aforementioned protocols.

@stephencelis
Copy link
Member

@fwcd Check out how we implemented it in swift-tagged: https://github.com/pointfreeco/swift-tagged/blob/f3f773a5e13f3c8f0ab1ce2ae6378058acefa87d/Sources/Tagged/Tagged.swift#L289-L314

I think you could do similar here to conditionally support any underlying collection that conforms to the ExpressibleBy* protocol.

@fwcd
Copy link
Contributor Author

fwcd commented Mar 15, 2022

That's a neat workaround to the issue that Swift doesn't have a spread operator yet and definitely the simpler solution.

Unfortunately, there is another issue, certain overloads now become ambigous with [3, 4, 5] being interpretable as both an array and a NonEmpty:

.../git/swift-nonempty/Tests/NonEmptyTests/NonEmptyTests.swift:124:20: error: ambiguous use of 'isDisjoint(with:)'
    XCTAssertFalse(NonEmptySet(1, 2, 3).isDisjoint(with: [3, 4, 5]))
                   ^
.../git/swift-nonempty/Sources/NonEmpty/NonEmpty+SetAlgebra.swift:75:15: note: found this candidate
  public func isDisjoint(with other: NonEmpty) -> Bool {
              ^
.../git/swift-nonempty/Sources/NonEmpty/NonEmpty+SetAlgebra.swift:79:15: note: found this candidate
  public func isDisjoint(with other: Collection) -> Bool {
              ^

@stephencelis
Copy link
Member

Unfortunately, there is another issue, certain overloads now become ambigous with [3, 4, 5] being interpretable as both an array and a NonEmpty:

Hm! Could you try adding a @_disfavoredOverload annotation to the one that takes a NonEmpty?

@fwcd
Copy link
Contributor Author

fwcd commented Mar 15, 2022

That did the trick, thanks! The test suite now passes.

@fwcd fwcd marked this pull request as ready for review March 15, 2022 21:37
Copy link
Member

@stephencelis stephencelis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Thanks for taking the time to contribute 😄

@stephencelis stephencelis merged commit 6a39025 into pointfreeco:main Mar 15, 2022
@fwcd fwcd deleted the expressible-by-conformances branch March 21, 2022 00:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ExpressibleByArrayLiteral and ExpressibleByDictionaryLiteral conformances
2 participants