-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Proposal: await? (Null-aware await) #7171
Comments
I was thinking that this is already proposed, but didn't find anything. |
I think this is more dangerous than valuable.
That mistakenly returns
Enabling awaiting a This may be mitigated with having non-nullable reference types(#5032) as a prerequisite and restricting the usage of |
👎 on How much of a breaking change would it be if
wouldn't throw a null reference. Instead it would return the default value of the result type. |
I'm thinking about a more generized solution for this; if forward pipe operator (#5445) works with var result = arg |> await Foo.BarAsync(); or with help of #5444, (from #4714 comment) string result = await client.GetAsync("http://microsoft.com")
|> await ::Content.ReadAsStringAsync(); Then, using a null-aware forward pipe operator, the example above could be written like this: var result = obj as IFoo ?> await ::FooAsync(); or any other syntax. |
@alrz of course you shouldn't return Non-nullable reference types help because the compiler can enforce that |
That would be confusing regardless of a breaking change. I liked @i3arnon suggestion to make await nonNullableAwaitable;
await? nullableAwaitable; // returns null
await nullableAwaitable!; // throws
await! nullableAwaitble; // might be better By the way, #5032 needs more support in other places too, like #6563, foreach(var item in nullableList) {} // shouldn't work
foreach?(var item in nullableList) {} // use this, instead of
if(nullableList != null) foreach(var item in nullableList) {}
foreach(var item in nullableList!) {} // note: if you prefer an exception
foreach!(var item in nullableList) {} // might be better Or forward pipe operator (#5445), nullable |> FuncitonTakingNonNullable(); // wouldn't work
nullable ?> FuncitonTakingNonNullable(); // use this, instead of
if(nullable != null) FuncitonTakingNonNullable(nullable);
FuncitonTakingNonNullable(nullable!); // note: this might throw |
What would be confusing about it? Currently §7.7.6 states:
The spec could be changed to avoid the null reference exception:
As far as I can tell, the result would be exactly the same (aside from a state machine member type change and a few IL instructions) in all cases where |
@bbarry The problem is with this part
Same would be true for |
also Quoting @gafter (#6400 (comment)):
|
@bbarry I don't know what is the difference between implicitly throwing |
This might be complicated on the compiler side but it might be a nice solution if ?. could look to the right hand side of the expression, and return a completed Task if an async method is called on null. The await would then just do its normal thing. Ie instead of returning |
What would it be if |
@DiryBoy I think this is related to #5032 whereas |
@alrz Ok, so my question is not applicable here actually. |
|
I like @bbarry's suggestion that |
It might not be as pretty and I'm all for the nullable await but we need the a GetValueOrDefault() just like for nullable. Here's an extension method that works if anyone is interested.
I've tested it and this works and it's easy enough for me to stick with. |
One case where I've often wished for something like
|
We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages. See also dotnet/csharplang#35 for a proposal under consideration. |
why this proposal got rejected? its perfect use case is for null-able types. |
What makes you think the proposal was rejected? Read gafter's last comment. |
@MkazemAkhgary, read the last message from @gafter. There's an open issue on the C# language repo for this: dotnet/csharplang#35 |
@jnm2 @paulomorgado I see, I should've noticed more carefully, thanks a lot. |
Innocent
NO!!! ugly fix
|
Currently you can't use
await
and null coalescing operator together, likeIt would be nice if we could make
await
aware of nulls, likeInstead of
Or
Although, this can be done with pattern-matching
But still, it's too verbose for such a simple task; for
await foo.Bar?.FAsync()
this wouldn't apply though.The text was updated successfully, but these errors were encountered: