Target-typed casting

[vc-74]

target-typed new expressions are a great way to improve code readability. A similar idea could be applied when declaring a variable and assigning it from the result of an explicit cast.

For instance, instead of:
var list = (IReadOnlyList<int>)collection;
or
IReadOnlyList<int> list = (IReadOnlyList<int>)collection;

we could write
IReadOnlyList<int> list = collection!;

The bang operator is just used to provide a syntax example and a different syntax could be used as long as

• The type to cast to precedes the variable name
• The type to cast to is not repeated in the expression

ed: adding more details following the comments below:

To me target-typed new expressions have been created to improve readability of variable declaration and assignment on the same line and avoid having to duplicate the type.

Before them, we could write:
Class c = new Class()
and
var c = new Class()

In the first case, it's obvious that c is a Class since the type precedes the name of the variable, but the type is duplicated.
In the second it is not duplicated but it's a little bit less obvious to know what c is.

Target-typed new expressions allow the best of both worlds:
Class c = new()

My suggestion is to add a similar feature to other declaration + assignment cases, in particular when declaring a variable and assigning it to the result of an explicit cast.

[FaustVX]

Everything you asked already works

IReadOnlyList<int> list1 = collection;
var list2 = (IReadOnlyList<int>)collection;
IReadOnlyList<int> list3 = (IReadOnlyList<int>)collection;

sharplab.io

[vc-74]

@FaustVX what I'm suggesting here is a new syntax for those casting cases (assuming collection is an IEnumerable<int> for instance).

[jnm2]

@HaloFour It's okay that that's already legal syntax, so long as this proposal would only change behavior of currently non-compiling code.

[HaloFour]

Perhaps, but the only reason that code wouldn't compile before would be because the lack of an implicit cast. So that eould overload the null forgiveness operator, which very explicitly does not change runtime behavior, with a new operator that does and would be very easy to miss.

IMO explicit casts should be that, explicit and obvious, as the developer declares their intent to the compiler that they know that the cast is narrowing and could fail at runtime. I don't think the null forgiveness operator would be the right syntax to consider as an alternative syntax for explicit casting.

[vc-74]

@HaloFour Do you mean you think that using the suggested syntax makes the cast less obvious?

[HaloFour]

@vc-74

Yes, specifically because null forgiving operators can be used in assignment statements now and that operator is explicit documented to not change runtime behavior.

[vc-74]

I used ! as an example, a different syntax could be used if needed

[jnm2]

This would be similar to how foreach (Bar bar in foos) casts foos items to Bar, and same with the LINQ syntax from Bar bar in foos.

[TahirAhmadov]

The gist of the request, the way I understand it, is that you want ! operator to have a separate meaning: in addition to the long time boolean negation, and the more recent null forgiveness, you want it to now also mean explicit casting.

The problem is that in those types of expressions the ! already has a different meaning. With boolean negation, it's used in a different context, which is why it was possible to re-use it for the null forgiveness - it appears at the end of a reference type expressions, as opposed to in front of a boolean typed expression. However, with explicit casting, ! after a reference type already has a meaning; your new "explicit cast" meaning would directly conflict with existing semantics, making this a non-starter.

Also, even if we were to find a different symbol other than ! for explicit casting, what's wrong with var list = (IReadOnlyList<int>)collection;?

[vc-74]

Nothing per se, it's just that with target-typed new expressions the types are all to the left side of the assignment expression.

[HaloFour]

Yes, but with target-typed new expressions there is no coercion or cast, the type on the left is the same as the type on the right. That's not true in this case.

[jnm2]

the syntax of this feature could differ as long as

• The type to cast to is to the left of the expression
• The type to cast to is not repeated in the expression

These criteria are already satisfied by the var form. Why is this not a great existing solution?

The only thing I could think of was that ! is postfix and that is convenient. An idea that's been brought up a few times by an LDM member or two is postfix casts (request at #5447), looking something like:

var list = collection.(IReadOnlyList<int>);

[vc-74]

These criteria are already satisfied by the var form. Why is this not a great existing solution?

Not quite, by to the left I mean something similar to target-typed new expressions:

List<int> list = new()

[jnm2]

Oh, do you mean target-typing rather than relative lexical position? For instance, do you mean this would also work?

M(collection!);

void M(List<int> list) { }

[vc-74]

No I don't think it's worth going this far.
To me target-typed new expressions have been created to improve readability of variable declaration and assignment on the same line and avoid having to duplicate the type.

Before them, we could write:
Class c = new Class()
and
var c = new Class()

In the first case, it's obvious that c is a Class since the type precedes the name of the variable, but the type is duplicated.
In the second it is not duplicated but it's a little bit less obvious to know what c is.

Target-typed new expressions allow the best of both worlds:
Class c = new()

My suggestion is to add a similar feature to other declaration + assignment cases, in particular when declaring a variable and assigning it to the result of an explicit cast.

[Richiban]

Why do you want to be able to write IReadOnlyList<int> list = collection!; when IReadOnlyList<int> list = collection; already works (without the bang !). Perhaps I've misunderstood your request, but if you're going to write the type on the left then you can assign what you need without casting at all.

[jnm2]

It does not work if collection is a less-specific type.

[vc-74]

It does not work if collection is a less-specific type.

Exactly

[Richiban]

Now I'm with you! You want to automatically downcast (or explicit cast?).

I'm pretty sure I've seen a request like this before; IIRC that proposed to allow casting to var. So:

IEnumerable<string> strings = new List<string>();

IReadOnlyCollection<string> string2 = (var)strings;

I'll see if I can find it.

[Richiban]

Here: #4428

[vc-74]

Indeed, it looks like a similar feature, thanks. I'm not sure var is a good choice of keyword however, it doesn't clearly convey the idea of explicit casting.