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

Validate that self is only used in escaping closures and conflicts #59

Closed
jpsim opened this issue May 28, 2015 · 19 comments
Closed

Validate that self is only used in escaping closures and conflicts #59

jpsim opened this issue May 28, 2015 · 19 comments
Assignees

Comments

@jpsim
Copy link
Collaborator

jpsim commented May 28, 2015

Use of self should be limited to escaping closures and scopes in which other declarations conflict.

@jpsim jpsim changed the title Validate that the self is only used in escaping closures and conflicts Validate that self is only used in escaping closures and conflicts Jan 29, 2016
@scottrhoyt
Copy link
Contributor

Counterpart of #321

@eneko
Copy link

eneko commented Feb 3, 2016

👍

@diederich
Copy link

Love this. It would make searching for ref-cycles quiet a bit easier... :-)

@charleyfromage
Copy link

I could find the "explicit_self" rule but I couldn't find the identifier for this one.

Anyone could help me with finding it ?

Thanks!

@jpsim
Copy link
Collaborator Author

jpsim commented Nov 28, 2018

Anyone could help me with finding it ?

Doesn't exist yet. If anyone would like to build this rule, please go ahead!

@ptrkstr
Copy link

ptrkstr commented Aug 6, 2020

Any update on this?

@stale
Copy link

stale bot commented Nov 8, 2020

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

@stale stale bot added the wontfix label Nov 8, 2020
@stale stale bot closed this as completed Nov 15, 2020
@sethfri
Copy link
Contributor

sethfri commented May 2, 2021

Reopening, as there is still demand for this rule based on #3579 and prior comments on 2020.

@sethfri sethfri reopened this May 2, 2021
@sethfri sethfri removed the wontfix label May 2, 2021
@pronebird
Copy link

Would love to see that implemented.

@YannickGagnon
Copy link

Any status update on this "implicit_self" rule inclusion? 🤔

Thanks

@lizjakubowski
Copy link

bump - my team would find this rule to be super useful ❤️

@mqln
Copy link

mqln commented Jun 7, 2022

Bumptiybumpbump.

Any status updates on this issue? I think we all want it ❤️

@amadeu01
Copy link

amadeu01 commented Jul 7, 2022

Any updates on this?

@TripwireNL
Copy link

Has this been implemented already? I would love to have this rule in SwiftLint!

@acicartagena
Copy link

hello, bump any updates on the concerns/challenges of implementing this?

@mqln
Copy link

mqln commented Dec 6, 2022

Bumpbumpbump part 2?

@SimplyDanny
Copy link
Collaborator

SimplyDanny commented Apr 20, 2023

I've implemented parts for this rule in #4911. As mentioned there, what's missing are two cases is one case:

  • Weakly captured self with explicit unwrapping according to SE-0365
  • Implicit self in classes when the closure isn't @escaping

These It can be implemented in a later step (probably as a separate Analyzer rule). I didn't want to make the first implementation overly complex and rather gather your feedback on other cases I might have missed.

Please have a look into the PR and let me know which other test cases you can think of, what I've missed or what doesn't work like the rule assumes!

@SimplyDanny
Copy link
Collaborator

Closing this as completed. The remaining part "implicit self in classes when the closure isn't @escaping" is requested by #4964.

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