-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
as expressions #845
Conversation
There was a problem hiding this 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.
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.
There was a problem hiding this 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.
There was a problem hiding this 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.
This isn't an alternative; it's complementary to the current proposal.
There was a problem hiding this 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...
There was a problem hiding this 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.
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]>
This proposal provides an
as
expression for casting. This supports implicit conversions plus some safe and unsurprising conversions that we do not support implicitly:bool
to integer typesThis facility can be extended by implementing the
As(TargetType)
interface for a type.