[Proposal]: add "when" variants for return, continue, break and throw statements

[dmitrykolchev]

Add "when" variants for return, continue, break and throw statements

I have doubts about the usefulness of these extensions, but I think it makes sense to consider it

#176
#6345

Motivation

Lines like the ones below are very common in the code

Example 1

if (updateResult != 0)
{
    return updateResult;
}

Example 2

if (!File.Exists(nupkgPath))
{
    throw new Exception($"Could not download package {id} @ {version} using any input feed");
}

Example 3

// Don't bother generating empty ItemGroup elements.
if (!group.Packages.Any())
{
    continue;
}

The code blocks above can be rewritten with "when" variants without using "if" statement as

return updateResult when updateResult != 0;

throw new Exception(message) when !File.Exists(nupkgPath);

// Don't bother generating empty ItemGroup elements.
continue when !group.Packages.Any();

[HaloFour]

This isn't any different to the linked discussion. As stated there, you can already write those examples as a single line by omitting the block:

if (updateResult != 0) return updateResult;

if (!File.Exists(nupkgPath)) throw new Exception($"Could not download package {id} @ {version} using any input feed");

if (!group.Packages.Any()) continue;

[dmitrykolchev]

I understand your point.
But it's not a matter of what I can or can't do. It is primarily a question of semantics and what I want to do. In all these cases return, throw, continue etc. is what I want to do when some conditions met, if-statement masks the action by bringing itself to the foreground

[HaloFour]

That's intentional, the condition is the more important part of the statement. More importantly, it already wotks and is considered idiomatic.

[FaustVX]

@dmitrykolchev
To me, the condition is more important than the action.
Also when could means an event, but if is a condition, semantically it's not the same.
And, it's weird to have the condition written after the action. What happens if the condition have side effects like return i when i++ == 5, so first you do the i++ == 5 then the return i, it's complicated to follow.

[krisutofu]

I think, it would be more interesting and distinct from existing C# features when it would use a pattern (like the is-expression) instead of a generic boolean expressions because it would provide the benefit of avoiding redundant variables and also is not artifically constrained to certain language keywords.

velocity += acceleration if not null;

(Skips the statement when acceleration is null.)

return vector.Cross(vector2) / vector.length()
    if not float.NaN;

It reads more like a mathematical formula where the condition also is put behind the cases.

There is a good argument for putting conditions after the behaviour because the behaviour of a function is of central interest when flying over foreign code. There are sufficiently many cases where if-conditions are trivial implementation details and impede the reading flow. But C# has already adopted some of C's syntax fragments and therefore, there is few or no reason to replace it with just another syntax. It should rather add a new way of coding.

I could imagine, if C# is ever willing to integrate theorem solving capabilities into it (which I think is part of the future in programming), then the proposed syntax could be useful:

return Foo(x) if var x and > 3;

Returns some fixpoint of Foo(x) that is > 3.

return Mathf.Max(Foo(x)) if var x;

Returns the maximum fixpoint of Foo. The keyword does not actually matter, it could also be when or where (which is more common for this usage).

It could also be useful as unification operator, returning the unification result.

Generalized, it works on arbitrary expressions and patterns, even on subexpressions of bigger expressions, and could be concatenated like the ternary operator.

<expression> if <pattern> [else …]

Example, rotate a box if it makes sense:

box.Rotate(
    vector if not null
    , angle if not float.NaN
);         

The benefit is, it doesn't require the reader to read one complex if-condition at once. One can directly see that a Box Rotation is the code behaviour and could choose to skip the nested expressions or read them.

I would like it if we could use patterns as alternative type annotations for declarations (inspired from constraint programming).

int x where > 5;

All of this is likely too radical anyways and does not really fit to the "C" in C#. So, I would see this just as inspiration of what could be possible in language design.

[huoyaoyuan]

I put serious downvotes to such Englism in programming language. It's just grammar order in English sentence. Putting conditions behind the main clause can be counter-intuitive for other language speakers.

For programming language, the best order is execution order. Subclause goes executed/tested first should go first.