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-1009] Add methods to an Array containing a specific type #43621

Closed
swift-ci opened this issue Mar 21, 2016 · 9 comments
Closed

[SR-1009] Add methods to an Array containing a specific type #43621

swift-ci opened this issue Mar 21, 2016 · 9 comments

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Mar 21, 2016

Previous ID SR-1009
Radar rdar://problem/17821143
Original Reporter mattdipasquale (JIRA User)
Type New Feature
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels New Feature
Assignee @slavapestov
Priority Medium

md5: b6b1e530310ef2059d8fb2110e717e5f

is duplicated by:

  • SR-1447 Concrete same-type requirements

Issue Description:

For example, if I'd like to activate the constraints inside of constraints: [NSLayoutConstraint], instead of writing NSLayoutConstraint.activateConstraints(constraints), I'd like to write constraints.activate(). However, the compiler should only allow calling activate() on an array if the contained type implements activate(). Note: Apple's documentation says: "Typically, using [the activateConstraints()] method is more efficient than activating each constraint individually." So, constraints.activate() would be faster than constraints.map { $0.active = true }.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Mar 21, 2016

The syntax for this would be

extension Array where Element: NSLayoutConstraint {
  func activate() { … }
}

except we haven't implemented that yet. @DougGregor, do you remember where we are with that?

@belkadan
Copy link
Contributor

@belkadan belkadan commented Mar 21, 2016

Actually, the version with : (as opposed to ==) might already work.

@DougGregor
Copy link
Member

@DougGregor DougGregor commented Mar 21, 2016

We've been doing some of the infrastructural work that would enable this feature, but nobody is actively working on the implementation of this feature (which we refer to as "concrete same-type requirements" on https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html)

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Mar 21, 2016

Comment by Matthew Mario Di Pasquale (JIRA)

Cool! :) Glad this is already on the radar. Thank you for the updates, @belkadan & @DougGregor, and thank you for all your legendary contributions to Swift. :) I'm honored to be of assistance.

@karwa
Copy link
Contributor

@karwa karwa commented Jun 23, 2016

@belkadan@DougGregor Does this look like a reasonable fit for Swift 3? Has that infrastructure worked progressed to a point where somebody could pick up implementing this feature?

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Jun 23, 2016

Unfortunately there's still a fair bit of work remaining before we can tackle this, I'm afraid. SILFunction::ContextGenericParams probably has to go away and be replaced with an ArrayRef<Substitution>.

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Sep 7, 2016

An update: we're getting closer. SILFunction::ContextGenericParams is gone, and so is the canonical mangling signature stuff. Next step is to remove the archetype from AbstractTypeParamDecl; I'm working on that now.

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Oct 5, 2016

Here it is: #5126

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Oct 5, 2016

Merged.

@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
Projects
None yet
Development

No branches or pull requests

5 participants