Skip to content

Implement SE-0068: Expanding Swift Self to class members and value types #3866

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

Closed
wants to merge 1 commit into from

Conversation

joewillsher
Copy link
Contributor

What's in this pull request?

Implementation start on SE-0068. This does not yet implement allowing Self to refer to the dynamic type in non final classes outside of function signatures, just expanding Self to value types.

Resolved bug number: (SR-1340)


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library only for macOS. Simulator standard libraries and
    device standard libraries are not built.
  3. lldb is not built.
  4. The test and validation-test targets are run only for macOS. The optimized
    version of these tests are not run.

A smoke test on Linux does the following:

  1. Builds the compiler incrementally.
  2. Builds the standard library incrementally.
  3. lldb is built incrementally.
  4. The swift test and validation-test targets are run. The optimized version of these
    tests are not run.
  5. lldb is tested.

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

…d value types

‘Self’ type is now resolved to the type of the local type context.
@joewillsher
Copy link
Contributor Author

@tkremenek Here is a PR which implements most of SE-0068 for Swift 3

@tkremenek
Copy link
Member

@swift-ci smoke test

@tkremenek
Copy link
Member

@joewillsher thanks! Will have a couple people review this change.

@slavapestov
Copy link
Contributor

What happens if you use Self inside a non-Self-returning class method? Does it still work?

@joewillsher
Copy link
Contributor Author

joewillsher commented Jul 29, 2016

I’m running tests on that updated version now — I can submit separately when it is ready.



/// Retrieve the nearest enclosing nominal type context.
NominalTypeDecl *getEnclosingNominalContext() const;
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick: I don't think it's correct to say a nominal is "enclosing" when you're in an extension.

Copy link
Contributor

Choose a reason for hiding this comment

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

getInnermostTypeContext()->getDeclaredTypeInContext()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a refactor of a global static function, but I will remove it and replace it with that, thanks

@joewillsher
Copy link
Contributor Author

joewillsher commented Jul 30, 2016

@jrose-apple I have made a bunch of these changes as well as finish of the rest of the SE proposal implementation, but there are still a few issues.

@joewillsher
Copy link
Contributor Author

Adding Self to dynamic contexts has proven difficult — it ends up hitting lots of SILGen edge cases when the DynamicSelfType and the concrete type get used interchangeably.

I’m going to have to look at changing the hasDynamicSelf mechanism on functions and figure out how to cannonicalise non-final-class's DynamicSelfType without all the special cases it has now.

I will close this PR now and will open a new one when that work is complete.

@joewillsher joewillsher closed this Aug 1, 2016
@jckarter
Copy link
Contributor

jckarter commented Aug 1, 2016

@slavapestov and @rjmccall have some short- and long-term ideas for improving how Self types get lowered in SIL. The current representation is pretty bogus. You might want to coordinate with them.

@joewillsher
Copy link
Contributor Author

joewillsher commented Aug 1, 2016

Thanks Joe. Slava and John I would really appreciate some pointers here, this proposal requires some significant changes to this area and I’m not sure how to approach it. I’d be happy to work on implementing any ideas you have, thanks.

@jckarter
Copy link
Contributor

jckarter commented Aug 1, 2016

I think the proposal as written is reasonable, but the compiler implementation needs a lot of work to live up to it.

@slavapestov
Copy link
Contributor

@joewillsher I think a good start is to put 'Self' behind a staging flag for now.

Another thing to try is to give 'self' the dynamic 'Self' type in all class methods, not just those returning 'Self', again, guarding this with a staging flag. Presently, this will result in some optimizer regressions, but it might allow you to make more progress with the language change.

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.

5 participants