Proposal: Make "throw expression" an expression form

[gafter]

The spec has been moved

The spec for the proposed throw expression has been moved to https://github.com/dotnet/roslyn/blob/future/docs/features/patterns.md

Below is a snapshot that may be out of date.

---

I propose to extend the set of expression forms to include

throw-expression:
      throw null-coalescing-expression
null-coalescing-expression:
      throw-expression

The type rules are as follows:

A throw-expression has no type.
A throw-expression is convertible to every type by an implicit conversion.

The flow-analysis rules are as follows:

For every variable v,

• v is definitely assigned before the null-coalescing-expression of a throw-expression iff it is definitely assigned before the throw-expression.
• v is definitely assigned after throw-expression.

A throw expression is allowed in only the following contexts:

• As the second operand of a ternary conditional operator ?:
• As the third operand of a ternary conditional operator ?:
• As the second operand of a null coalescing operator ??
• After the colon of a match section (see Proposal: expression-based switch ("match") for pattern matching #5154)
• As the body of an expression-bodied lambda or method.

---

This proposal is intended to facilitate a move toward expression-oriented programming, adding convenience in a number of scenarios. For example

An expression-bodied method may now throw

void M() => throw new NotImplementedException();

A conditional expression may throw on one branch:

var foo = term.HasValue ? term.Value.Foo() : throw new ArgumentException("term");

I am proposing this to facilitate a proposal (#5154) for an expression form of a pattern-matching switch, where one may want to throw in some branch.

This is related to #59 and #1226.

[aluanhaddad]

This is a wonderful idea. It is simple, it paves the way for future constructs. It will improve many existing language features, such as lambda expressions, and by extension that will improve the elegance of certain patterns, such as dispatch dictionaries.

[olmobrutall]

I like this solution, but It can be implemented today with this nice trick:

public static T Throw<T>(this Exception ex)
{
     throw ex;
}

And used like:

var foo = term.HasValue ? DateTime.Now : new ArgumentException("term").Throw<DateTime>();

Just my 2 cents...

[gafter]

@olmobrutall That does not have the correct definite-assignment behavior.

[olmobrutall]

@gafter Can you elaborate on that? I need an example to understand the following sentence

v is definitely assigned before the expression of a throw-expression iff it is definitely assigned before the throw-expression.

Still, just for the sake of discoverability, I like your proposal very much.

[gafter]

Yes, what that means is that in an expression of the form throw e any variables that are definitely assigned before throw e are definitely assigned before e. The example is

Exception x = new Exception();
var q = condition ? 2 : throw x; // is x definitely assigned here?

We need the quoted rule to answer that question.

[olmobrutall]

Mmmm... Then what's the problem with the Throw<T> definitely assignment?