Revisiting requiring explicit `self.` when passing a method as an escaping closure

Evolution Pitches
18

To summarize the discussion so far, here are the additional suggestions that I've noticed in this thread:

  1. Add syntax for weakly capturing self, without creating an explicit closure (via @broadway_lamb -- link)
  2. Extend this requirement to cases where strong self escapes via a locally-declared function (via @hartbit -- link)
  3. Loosen the explicit self. requirement for cases where self is not a reference type (via @dabrahams -- link)

It's really helpful to see these additional ideas, since it's important to keep the big picture in mind when proposing changes to the language.

I like the scope of the change I've proposed because it addresses a real pain point (for me at least), seems like it will be reasonably easy to implement, and shouldn't conflict with any of these other suggestions.

I think a formal discussion would be helpful now, so I'm going to write up a draft proposal and solicit feedback on that.

Thanks for all of your responses!

1 Like