close
Skip to content

[SE-0096] Implement type(of:)#3878

Merged
CodaFi merged 4 commits intoswiftlang:masterfrom
CodaFi:decltype
Jul 30, 2016
Merged

[SE-0096] Implement type(of:)#3878
CodaFi merged 4 commits intoswiftlang:masterfrom
CodaFi:decltype

Conversation

@CodaFi
Copy link
Copy Markdown
Contributor

@CodaFi CodaFi commented Jul 29, 2016

What's in this pull request?

In the interest of getting this patch in quickly (and because I already have the work done) this patch is going to supersede #3871.

Resolved bug number: (SR-2218)


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.

@CodaFi
Copy link
Copy Markdown
Contributor Author

CodaFi commented Jul 29, 2016

@swift-ci please smoke test.

@CodaFi
Copy link
Copy Markdown
Contributor Author

CodaFi commented Jul 30, 2016

:shipit:

@CodaFi CodaFi merged commit b79fa44 into swiftlang:master Jul 30, 2016
@CodaFi CodaFi deleted the decltype branch July 30, 2016 01:05
@rxwei
Copy link
Copy Markdown
Contributor

rxwei commented Jul 30, 2016

Cool 👍 Are we keeping compatibility with x.dynamicType? And we may want to highlight type and of as a keyword, when they appear together.

@CodaFi
Copy link
Copy Markdown
Contributor Author

CodaFi commented Jul 30, 2016

This change is source breaking. It will be compatible until the next patch where I yank support for dynamicType out of the compiler 😎.

Comment thread lib/Parse/ParseExpr.cpp
if (Tok.canBeArgumentLabel() && peekToken().is(tok::colon)) {
bool hasOf = Tok.getText() == "of";
if (!hasOf) {
// User mis-spelled the 'of' label.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Does this mean it's impossible for user code to define a function named type (with any argument label)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It does. It is a limitation of the SE that deserves to be discussed. One solution would be to make this a "magic hash-prefix" function like #selector.

Copy link
Copy Markdown
Contributor Author

@CodaFi CodaFi Jul 30, 2016

Choose a reason for hiding this comment

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

Originally we wanted this function defined in stdlib and not in the parser. But that can't happen for bureaucratic reasons related to protocols and other nominal types having differing expressions allowed after these dynamicType contexts.

Copy link
Copy Markdown
Contributor Author

@CodaFi CodaFi Jul 30, 2016

Choose a reason for hiding this comment

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

Nevertheless, I think I'm going to disable this diagnostic when I do the next patch to properly remove the keyword and make the parser fall back to find user-defined functions.

@rintaro rintaro mentioned this pull request Jul 30, 2016
1 task
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.

3 participants