Skip to content

v7.x Q re throw expressions #66

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
RexJaeschke opened this issue Dec 10, 2020 · 6 comments
Closed

v7.x Q re throw expressions #66

RexJaeschke opened this issue Dec 10, 2020 · 6 comments
Assignees
Labels
type: feature This issue describes a new feature
Milestone

Comments

@RexJaeschke
Copy link
Contributor

In Draft PR #65, I've added almost all the edits to support the addition of throw expressions. Here's what's missing:

  1. I've added the new section "The throw expression operator" to the the Expressions clause, but it needs to be "plugged into" the grammar, so it has precedence. (Also, for now, I've put this new section under primary expressions, but that might not be correct.)
@RexJaeschke RexJaeschke added this to the C# 7.x milestone Dec 10, 2020
@jskeet jskeet added the type: feature This issue describes a new feature label Jan 7, 2021
@KalleOlaviNiemitalo
Copy link
Contributor

The interaction of #65 and #213 does not allow a throw expression as an operand of a ref conditional expression:

ref int F(bool b, ref int i) => ref b ? ref i : ref throw null;

because "Both expressions shall be variables having the same type" and "A throw_expression has no type." I suppose this restriction is by design.

@BillWagner
Copy link
Member

See PR #65

Note that instead of "primary", the throw expression precedence should be the same as the null coalescing question.

@jskeet jskeet self-assigned this Oct 5, 2022
@jskeet
Copy link
Contributor

jskeet commented Oct 7, 2022

@KalleOlaviNiemitalo: It's not clear to me from your comment whether this is how the compiler actually behaves, or whether this is an area you think this needs a spec change. I want to close this issue when #65 is merged, so please could you file a new issue if you believe we need to do more work on this?

@KalleOlaviNiemitalo
Copy link
Contributor

@jskeet the standard text matches compiler behaviour and I think the behaviour is reasonable so no action is required.

@BillWagner
Copy link
Member

@jskeet PR #65 has been merged. I think that the questions raised here have been answered.

Can we close this as fixed in #65

@jskeet
Copy link
Contributor

jskeet commented Dec 1, 2022

Yes, I think so.

@jskeet jskeet closed this as completed Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature This issue describes a new feature
Projects
None yet
Development

No branches or pull requests

4 participants