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

as expressions #845

Merged
merged 19 commits into from
Oct 29, 2021
Merged

as expressions #845

merged 19 commits into from
Oct 29, 2021

Conversation

zygoloid
Copy link
Contributor

@zygoloid zygoloid commented Sep 22, 2021

This proposal provides an as expression for casting. This supports implicit conversions plus some safe and unsurprising conversions that we do not support implicitly:

  • lossy but fully defined conversions to floating-point types
  • conversion from bool to integer types
  • conversion between adaptors and their adapted type, and more generally between compatible types

This facility can be extended by implementing the As(TargetType) interface for a type.

@zygoloid zygoloid added the proposal A proposal label Sep 22, 2021
@zygoloid zygoloid requested a review from a team September 22, 2021 00:53
@google-cla google-cla bot added the cla: yes PR meets CLA requirements according to bot. label Sep 22, 2021
Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

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

Some high level early feedback as requested.

docs/design/expressions/README.md Show resolved Hide resolved
docs/design/expressions/as_expressions.md Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
rather than suggesting it's the semantic foundation of implicit
conversions.

The lossless + semantics-preserving rules should be sufficient to
identify what an implicit conversion does.
unsafe_as -> assume_as.
@zygoloid zygoloid marked this pull request as ready for review September 25, 2021 00:44
@zygoloid zygoloid requested a review from a team as a code owner September 25, 2021 00:44
@github-actions github-actions bot added the proposal rfc Proposal with request-for-comment sent out label Sep 25, 2021
docs/design/expressions/as_expressions.md Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/lexical_conventions/words.md Outdated Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
proposals/p0845.md Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
proposals/p0845.md Show resolved Hide resolved
proposals/p0845.md Show resolved Hide resolved
Copy link
Contributor Author

@zygoloid zygoloid left a comment

Choose a reason for hiding this comment

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

Addressed @josh11b's comments.

proposals/p0845.md Show resolved Hide resolved
proposals/p0845.md Show resolved Hide resolved
Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

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

This is looking really nice to me. I'm still interested in pushing a bit on the assume_as vs. unsafe_as. But if we're not converging there quickly, I'm also very open to breaking that out into a follow-up change (can even keep some or all of the content and just mark it as WIP / undecided).

Also might make sense to break out at least the discussion to an issue for leads.

docs/design/expressions/as_expressions.md Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
This isn't an alternative; it's complementary to the current proposal.
proposals/p0845.md Outdated Show resolved Hide resolved
proposals/p0845.md Show resolved Hide resolved
Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

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

Pretty happy with the more minimal approach as a good place to start. Some minor comments inline, and trying to tie off some threads...

proposals/p0845.md Outdated Show resolved Hide resolved
docs/design/expressions/as_expressions.md Outdated Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
proposals/p0845.md Outdated Show resolved Hide resolved
Copy link
Contributor

@chandlerc chandlerc left a comment

Choose a reason for hiding this comment

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

Chatted a bit more with Jon and I think while there are persisting concerns we should move forward for now. We can change this later if needed, but lets see how this works out in practice.

@zygoloid zygoloid merged commit b49584d into carbon-language:trunk Oct 29, 2021
@github-actions github-actions bot added proposal accepted Decision made, proposal accepted and removed proposal rfc Proposal with request-for-comment sent out labels Oct 29, 2021
@zygoloid zygoloid deleted the proposal-as-expressions branch March 11, 2022 01:02
chandlerc pushed a commit that referenced this pull request Jun 28, 2022
This proposal provides an `as` expression for casting. This supports implicit conversions plus some safe and unsurprising conversions that we do not support implicitly:

* lossy but fully defined conversions to floating-point types
* conversion from `bool` to integer types
* conversion between adaptors and their adapted type, and more generally between compatible types

This facility can be extended by implementing the `As(TargetType)` interface for a type.

Co-authored-by: Geoff Romer <[email protected]>
Co-authored-by: josh11b <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes PR meets CLA requirements according to bot. proposal accepted Decision made, proposal accepted proposal A proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants