Skip to content

Sema: Variadic parameters are always @escaping and cannot be @autoclo… #4878

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

Conversation

slavapestov
Copy link
Contributor

  • Description: This fixes some oversights with the new @escaping attribute combined with varargs, as well as a long-standing issue with @autoclosure.
  • Scope of the issue: Anyone who defines a variadic function taking closures would have had to previously write @escaping, because the default behavior produced an array of non-escaping closures, which confused the rest of the type checker.
  • Risk: Low, just changes type resolution behavior during type checking. This is technically a source breaking change, but only on invalid code, I think.
  • Reviewed by: @milseman

…sure

A variadic parameter of function type must be @escaping -- we cannot
reason about an array of non-escaping closures, so this was a safety
hole.

Also, attempting to define an @autoclosure variadic did not produce a
diagnostic, but would fail later on if you actually tried to do
anything with it. Let's ban this completely.

Both changes are source breaking, but impact is limited to code that
was already only marginally valid.
@slavapestov
Copy link
Contributor Author

@swift-ci Please test

@slavapestov
Copy link
Contributor Author

@milseman Are you OK with taking this in?

@milseman
Copy link
Member

I agree, LGTM

Copy link
Member

@milseman milseman left a comment

Choose a reason for hiding this comment

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

This looks good.

@milseman milseman merged commit 68ff93a into swiftlang:swift-3.0-branch Sep 20, 2016
@jrose-apple
Copy link
Contributor

This did turn out to be source-breaking after all, SR-2907.

@slavapestov
Copy link
Contributor Author

Yeah, we knew it was source breaking all along, but we also thought the old behavior was just wrong.

@jrose-apple
Copy link
Contributor

Ah, I thought we decided the old behavior was wrong for non-escaping closures, not for escaping closures. That is, there's no way to write the code in 3.0 that would do the "right" thing that 3.0.1 does.

aaditya-chandrasekhar pushed a commit to val-verde/swift that referenced this pull request Sep 30, 2022
[pull] swiftwasm-release/5.7 from release/5.7
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.

4 participants