Proposal: New Contextual Keyword for "await ... ConfigureAwait(false)"

[casperOne]

Problem

When not working with a SynchronizationContext, it's recommended that you use ConfigureAwait(false) to indicate that a SynchronizationContext is not required on return from the awaitable.

Currently, the C# compiler always captures SynchronizationContext when calling await (without an explicit ConfigureAwait directive); this is a reasonable default when doing work close to the user interface or servicing the request in ASP.NET (the most prevalent uses for the default/ConfigureAwait(true)).

However, when working on the server side or in libraries, using ConfigureAwait(false) is nearly ubiquitous, and leads to a tremendous amount of repetitive typing.

Proposed Solution

A new contextual keyword that is used in conjunction with, or as a replacement to async.

I currently don't have a good idea of what that keyword should be, so for now, let's use foo as a placeholder.

When applied to anything that implements the awaitable pattern, it assumes ConfigureAwait(false) is attached to the result.

Examples

var task = Task.FromResult(new object());

// The following return the same value, with neither capturing the
// ambient SynchronizationContext.
// This is the current way.
var r1 = await task.ConfigureAwait(false);

// The new keyword ('foo' is the placeholder for it here)
// would assume ConfigureAwait(false).
// These are examples based on whether it's an addition to async
// or a new keyword on it's own.  Only one would be applicable.
// I'd prefer a single keyword, but can live with two.
var r2 = foo await task;
var r3 = foo task;

Notes

I've looked at the existing list of C# keywords and contextual keywords, but I can't find anything that makes sense to use for this case. It may require a new keyword/contextual keyword, but if something existing makes sense, then by all means, let's use that.

The point being, many developers tend to do a lot of library/server side work, and having to type ConfigureAwait(false) (even with Intellisense) is a lot of wasted energy.

[jnm2]

A helper method could cut down on the typing too.

[casperOne]

@jnm2 I don't see how, since you'd have to make that an awaitable and then call ConfigureAwait(false) on that.

Unless I'm missing something?

Additionally, with awaitable being a pattern, you'd have to create a new extension (assuming this is viable) for each type that is awaitable (see the new ValueTask<T> type as an example).

[Vlad-Stryapko]

@casperOne
I might be mistaken, but I think ConfigureAwait works only for Tasks, whilst await applies to anything awaitable. Are you proposing that your keyword should be limited only to Tasks? Should it work for other things that provide ConfigureAwait?

[HaloFour]

Technically C# knows nothing about SynchronizationContext or ConfigureAwait. Those are implemented internally within the BCL type TaskAwaiter. As long as the target supports a GetAwaiter method that returns something that fits the awaiter convention C# will allow you to await on it and it's up to that awaiter to handle whatever synchronization marshalling might be involved, if any.

A helper method could return the TaskAwaiter that has already had ConfigureAwait called on it. Would reduce keystrokes, but wouldn't eliminate the need for the additional call.

I'd prefer an assembly-targeted attribute over some new keyword which would have to be applied everywhere. For reference: https://github.com/dotnet/roslyn/issues/7673

[foxesknow]

Does it matter if certain things are in the BCL? C# knows about Monitor for lock, IEnumerable for foreach and IDisposable for using

[casperOne]

@Vlad-Stryapko With C# 7.0, you can await anything that is "Task-like"; this proposal targets those items that are "Task-like."

@HaloFour While an attribute would handle this, I don't like the precedent it sets; I can't think of any other attribute like this which alters how the compiler handles a keyword/section of code. The closest thing I can think of is the compiler flag for checked/unchecked overflow checking.

While I know there are other cases where the line of code is subject to interpretation based on contextual information that's not so obvious reading the line of code in question, I'd prefer that we go down those paths as infrequently as possible. I imagine there would be a tremendous amount of pain having to remember whether or not that assembly is set all the time (and then having to fish for it, since it can be in any code file in the assembly).

The referenced Roslyn issue does round up the pain points well.

[HaloFour]

@casperOne

With C# 7.0, you can await anything that is "Task-like"

You could always await anything that is task-like. The requirement is that the target can resolve a method GetAwaiter() that returns something that implements either INotifyCompletion or ICriticalNotifyCompletion, has a property bool IsCompleted { get; } and a method T GetResult(). For example, Task.Yield returns a YieldAwaitable and not a Task.

What C# 7.0 does is allow for async methods to return something other than Task<T>, Task or void, such as ValueTask.

My issue with something like another keyword is that it involves a language change for a BCL concern and that it still requires the author to remember to apply it all over the place. An async-capable library is likely going to apply this logic to literally every TaskAwaiter and expect that the use of await from the consumer will handle the correct synchronization. But if the goal is simply to make it less typing rather than to handle it correctly by default, I'd go with an extension method:

public static class TaskExtensions {
    public static ConfiguredTaskAwaiter NoSync(this Task task) => task.ConfigureAwait(false);
    public static ConfiguredTaskAwaiter<T> NoSync<T>(this Task<T> task) => task.ConfigureAwait(false);
}

Then you can use:

var r1 = await task.NoSync();

[casperOne]

@HaloFour

Reducing typing is one of the goals.

I don't agree that there's a "correct way [to handle this] by default." It's contextual. I do agree that when ConfigureAwait was introduced with async/await that they didn't make the decision that caused the least amount of pain (this is in hindsight, whereas they didn't have that luxury then).

I see how the extension can work now, thank you for that.

However, if we adopt your goal of "handling it correctly by default", then the extension method suffers the same issue that a new keyword does, you have apply it everywhere.

[MattDillard]

@ufcpp advocated an interesting approach in a related discussion: dotnet/roslyn#7673. The idea is to change the async method to return a different Task-like type that encapsulates ConfigureAwait(false).

To be sure, this still means that manual intervention is necessary somewhere to opt-in to this behavior.

[svick]

@MattDillard I don't like that that approach "leaks" to the signature of the method. It should be an implementation detail, not something that's visible from the outside.

[Luiz-Monad]

Its already leaked in so far as its observable external effects, I mean, if it wasn't, there wouldn't be a need for ConfigureAwait at all, because it change the behavior of the rest of the (user/your) code after a call to await.
It would probably be best to have a custom Task Type.
This is not implementation detail, its environmental detail, unless you want something even more abstract than Task.

[qrli]

However, when working on the server side or in libraries, using ConfigureAwait(false) is nearly ubiquitous, and leads to a tremendous amount of repetitive typing.

I don't quite agree with that. The only reason for ConfigureAwait(false) is to prevent single-thread synchronization context from deadlock, which is the case for GUI frameworks like WinForm/WPF. I don't know why you need it on the server side.

As per my understanding, the only case for ConfigureAwait(false) is for a library which may be consumed in WinForm/WPF. And even in this case, you don't need ConfigureAwait(false) everywhere. You only need it in public async functions (the entry points of the library), while all the inner-level awaits are already detached from the synchronization context.

---

[2017-12-22] Update for later readers. In legacy ASP.NET, deadlock will definitely happen if caller code try to get result synchronously e.g. by .Result or .Wait(). And there are some rare mythical cases even when you do not.

[svick]

@qrli

The only reason for ConfigureAwait(false) is to prevent single-thread synchronization context from deadlock, which is the case for GUI frameworks like WinForm/WPF. I don't know why you need it on the server side.

One reason is that the synchronization context in ASP.NET is also single-threaded (even though it's not bound to a specific thread), so you still need ConfigureAwait(false) to avoid deadlocks. (This does not apply to ASP.NET Core, which does not have a synchronization context at all.)

A second reason is performance: restoring the context is not free, so if you care about performance and you don't need the context, it's wasteful to restore it.

And even in this case, you don't need ConfigureAwait(false) everywhere. You only need it in public async functions (the entry points of the library), while all the inner-level awaits are already detached from the synchronization context.

That's not how ConfigureAwait(false) works. If you call an inner function in the first await, that function is still going to be called on the synchronization context, even if that first await had ConfigureAwait(false).

And it's not limited to those "first await" functions either. Consider this code*:

public async Task<string> GetData() => await GetA() + await GetB();

private async Task<string> GetA() => await GetFile("a.txt");
private async Task<string> GetB() => await GetFile("b.txt");

private async Task<string> GetFile(string name)
{
    using (var reader = new StreamReader(name))
    {
        return await reader.ReadToEndAsync();
    }
}

Where do you think it's safe to omit ConfigureAwait(false) in the above code? In particular, would it be okay if you used ConfigureAwait(false) everywhere except in GetB()? The answer is no, it's not okay. In my tests (on my computer, using a custom SynchronizationContext and empty files on SSD), in about 1 case out of 10 000, all the preceding awaits complete synchronously, so ConfigureAwait(false) in GetB() does make a difference.

And even if you do have the guarantee of being detached now, a seemingly innocuous code change can break it, so I think you should use ConfigureAwait(false) everywhere in libraries.

---

* Note that the code does not correctly set useAsync. But doing so is annoying and does not seem to change the result, so I didn't do it.

[qrli]

@svick

One reason is that the synchronization context in ASP.NET is also single-threaded (even though it's not bound to a specific thread), so you still need ConfigureAwait(false) to avoid deadlocks.

I don't think there is deadlock issue with ASP.NET:
https://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code

A second reason is performance: restoring the context is not free, so if you care about performance and you don't need the context, it's wasteful to restore it.

Context restore is pretty lightweight, which is just a few assignments, which is comparable to the call to ConfigureAwait().

And it's not limited to those "first await" functions either. Consider this code*:

No, I didn't say first. I said in public async. So for your example, you should do ConfigureAwait(false) for both awaits inside GetData() function, but not for the other private functions. Inside the function called by await x.ConfigureAwait(false), there is already no sychronization context, so more ConfigureAwait(false)'s bring you nothing but additional function call cost.

IMO, the core issue is the massive confusion caused by ConfigureAwait(false), and the "best practices" built atop the confusion.

[jnm2]

Inside the function called by await x.ConfigureAwait(false), there is already no sychronization context

That's not true until after the first await that the inside function performs. Async methods always start out executing synchronously with the SynchronizationContext still in place.

[qrli]

hmm... i'm confused too... it has to be

public Task<string> GetData() => Task.Run(async () => await GetA() + await GetB());

or use a helper function like

public async Task<string> GetData()
{
   await AsyncHelper.LeaveSynchronizationContext(); // which calls ConfigureAwait(false) inside
   return await GetA() + await GetB();
}

[jnm2]

Or just

public async Task<string> GetData()
{
   return await GetA().ConfigureAwait(false) + await GetB();
}

;-)

(The downside of AsyncHelper.LeaveSynchronizationContext is that it would have to await Task.Yield() or in some other way introduce an unnecessary context switch. Things that could have returned synchronously will now be forced to execute slower.)

[casperOne]

@jjxtra In addition to the reasons @CyrusNajmabadi mentioned, considering the discriminator isn't between client/server libraries, but where callbacks need access to synchronization contexts (or not), a global setting like that doesn't have the granularity needed to address the scenarios currently described in this issue.

[awaescher]

I don't like ConfigureAwait() as well but I don't really think it's that bad to add the method at the end of the async method. What really bothers me is the way this methods makes me think every single time.

So I came up with a simple aliasing and yes I know this has downsides, too. Another package (or code file) to add, a namespace to import and maybe more.

However, this shows the intent the developer had while the orignal design of ConfigureAwait() hides the intent and enforces bad practices.

So here are my thoughts and my "solution" if you want to call it that way.

• https://github.com/awaescher/ObviousAwait

I'd be happy to know what you think and maybe even see these methods in other projects one day.

[AartBluestoke]

as a halfway house, would it be possible to annotate a class, just like .ConfigureAwait(bool) is implementation dependent, the language would consider the implementation of [AwaitContextFree] to be implementation dependent. It'd be best if there was some way for the code generator or compiler to know what to do?
[AwaitContextFree]
class Foo
async Task x(){
await stuff(); //

As an implementation note the standard implementation could provide an interface IAsyncConfiguration {ConfigureAwait(bool)} and have Task implement it, and use that as a hook for this action.

It would depend on if we could make this a 0 cost abstraction.
I would imagine that await code generated when it can prove that there is no context could be simpler, when there isn't a need to manage the context.

[daiplusplus]

Thinking about how new pragmas like #nullable enable work in C# had me thinking of an alternative to introducing a new keyword or relying on extension-methods, or an assembly-level attribute:

It could be a new preprocessor keyword/directive in its own right as #await (like #nullable), or it could sit behind #pragma, e.g. #pragma await samecontext.

Options would be:

• #await capturedcontext - same as using ConfigureAwait(true) in every awaitable call.
• #await anycontext- same as using ConfigureAwait(false) in every awaitable call.
• #await default- same as not using ConfigureAwait at all.

As with other #pragma statements its "scope" is textual, not semantic, which makes it easier to have long runs of UI thread methods (which all need to resume in the same context) and long runs of utility/background/library code (which generally don't need to resume in the same context) in the same file. And as with #nullable it could be set as an MSBuild property to set the default for all files in the project.

If .ConfigureAwait() is used on an awaited call-site then that always takes precedence over this proposed #await/#pragma await.

class MyWpfWindow
{

    #await capturedcontext

    public async Task OnWpfButton1Click()
    {
        this.viewModel.Data = await this.BackgroundMethodAsync();
    }

    public async Task OnWpfButton2Click()
    {
        this.viewModel.Data = await this.BackgroundMethodAsync();
    }

    #await anycontext

    private async Task<MyData> BackgroundMethodAsync()
    {
        Data1 d1 = await this.LoadFromNetworkAsync();
        Data2 d2 = await this.LoadFromDiskAsync();
        return new MyData( d1, d2 );
    }

    private async Task<Data> LoadFromNetworkAsync()
    {
        // etc
    }

    private async Task LoadFromDiskAsync()
    {
       // etc
    }
}

• Pros:
  • Unlike with extension-methods this approach significantly reduces amount of keyboard typing required and reduces in-method visual clutter (though #await / #pragma await could still be used inside a method if so-desired).
  • Doesn't add a new keyword to the language, only a new #pragma
  • Puts the consumer of an async method in control, rather than the author of the async method (as an author isn't going to anticipate how their code will be used)
  • Allows fine-grained selection of await sites, instead of an assembly-wide attribute.
• Cons
  • Does add a slight amount of out-of-method visual clutter.
  • This approach does add a lot of visual clutter in the situation where a code-file frequently alternates between UI-thread and background utility methods in the same file.
  • Visual Studio / Roslyn Refactoring tools / Code-Fixes (like "Move $type to file...") would need to be updated to be-aware of the #await statement - though it would be just like they do with #nullable and #pragma warning disable CA1001

[Luiz-Monad]

#precisely

[daiplusplus]

I don't think you intended for this to be a direct reply to my post?

[Luiz-Monad]

no, it was a mistake, It was supposed to go on the main line.
(but I'm not sure if that should even go in the this topic/proposal, but its kind of related, I'll leave it here while I think)

[Luiz-Monad]

I don't know were it was mentioned, but I'm now using a custom Task implementation that always returns my own Awaiter that does what I want.
It could be a problem if you want your library to retain binary compatibility, I just broke it on mine to solve this problem. Other thing I did was having a custom Synchronization context in one of the projects that uses that library.
I don't see any other way of circumventing the default behavior. The CLR mostly does it right by setting the ConfigureAwait to false.
As a library user, it doesn't matter much, you mostly do var something, as its not wise to depend on types coming from other libraries, even thou I did something evil, narrowing cast from CustomTask to Task solved most of these problems.
But as library developer all this conundrum was kind of bad, it could be worse (I dunno how, but things can always be worse), its just annoying to have to see .ConfigureAwait(false) its a code smell.
In Kotlin, for example, you have explicit context, the difference is that Kotlin has syntax sugar for scoping blocks of code, so you set it up once before the block. Explicit is aways better, C#'s decision was bad, but Kotlin had the 20/20 hindsight of learning from C# failures

suspend fun Library() = taskWithCorrectContext { 
// just call suspend functions, the IDE puts an icon,
// this is where C# is better, await is explicit, ironic isn't
}

which is way better than

void Task Library() {
 //lots of configureawait(false)
}

The best I could do was.

void CustomTask<Something> Library() {
 //just await anything from your library of from the CLR, which already has the correct behavior.
}

I think the only real solution is dropping C# in favor of F#, you don't lose much, besides some refactor support in the IDE..

fun Library = async { 
// I wish the async was like this on C#, 
// perhaps we need Computation Expressions in C# !
let! = anythingAsync() 
//this is the best pattern ever, its also much cheaper 
// than Task for CPU bound things, not only I/O.
} |> Async.StartAsTask() 

F# does the ConfigureAwait for you, but you have to do that to export it to C#, which comes back round again, at least you only have to do once per function, and not once per await.

Of course nothing impedes you from having:

fun Library = asyncTask {
let! = anythingAsync()  
} //this is a Task
// indeed that was my final solution to the problem

So what I propose is adding computation expressions to C#, so there's a interface to control context, not just one kind of context, but anything that's a Monad.
Meanwhile, lets go to F#, C# needs to catch up to the innovations on programming languages.

[nathan130200]

To solves adding new keyword, instead why not using ! after await, to indicate that call will invoke .ConfigureAwait(false);

Task<int> Sum(int a, int b) => Task.FromResult(a + b);

int num = await! Sum(1, 2) // first call will invoke .ConfigureAwait(false)
  + await@ Sum(3, 4) // second call with invoke .ConfigureAwait(true) 
  + await Sum(2 + 1); // regular call.

Console.WriteLine("Sum of values is {0}", num);

Or can be added on end of method call.

int num = await Sum(1, 2)! // first call will invoke .ConfigureAwait(false)
  + await Sum(3, 4)!! // second call with invoke .ConfigureAwait(true) 
  + await Sum(2 + 1); // regular call.

For method call at end can be @ symbol or !! symbols.

Or instead of when is await! call ConfigureAwait(false), but when end of method calling ConfigureAwait(true)

int num = await! Sum(1, 2) // after keyword, first call will invoke .ConfigureAwait(false)
  + await Sum(3, 4)! // at end, second call with invoke .ConfigureAwait(true) 
  + await Sum(2 + 1); // regular call.

if both after await! or at end ! will thrown an error in compiler

Also adding #pragma like to configure await will be useful also.

[jjxtra]

Why can't this be a pragma or property in the csproj file? Global change of configure await of false instead of true by default? Then things are reversed and you only have to do configure await of true if you need to have the same context for some reason. I imagine server side code projects would be great candidates for this.

[HaloFour]

@jjxtra

I imagine server side code projects would be great candidates for this.

Server-side projects running on ASP.NET Core don't run with a SynchronizationContext, so there's no requirement to call ConfigureAwait. Legacy ASP.NET projects do use SynchronizationContext, but you can't just disable that across an entire project otherwise you'll lose the current request context and identity.

[jjxtra]

Are you sure? I see ConfigureAwait(false) literally everywhere in server code. Where is your reference that there is no sync context?

[jnm2]

https://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html among many others. .ConfigureAwait(false) makes no difference on normal ASP.NET Core even though there are several pressures leading to people writing .ConfigureAwait(false) uniformly anyway.

[jjxtra]

Thanks. Sharing this with my colleagues as they keep adding this everywhere. They are used to net framework where perhaps this was a different answer.

[DaZombieKiller]

Just throwing the idea out there, but what if await itself could take parameters which would be passed to a ConfigureAwait method on the awaitable via duck-typing?

For example:

await(false) SomeAsyncOperation();
// equivalent to:
await SomeAsyncOperation().ConfigureAwait(false);

This would allow custom awaitables to also provide their own ConfigureAwait method (potentially with different argument types other than bool) and have it work with this syntax.

[HaloFour]

The problem isn't with the syntax, there's a plethora of choices. The question is whether this belongs in the compiler at all, which is currently completely agnostic as to the synchronization policies offered by TPL or any other task library.

There are already means through which you can make the calls to ConfigureAwait(false) much more succinct, such as extension methods. Autocomplete already does most of the work here anyway. You can also temporarily disable the SynchronizationContext for a given scope, eliminating the need to call ConfigureAwait at all within that scope. This could be applied at the public boundary of a library.

Ultimately I think the biggest problem is a lack of understanding as to when one should use ConfigureAwait(false), which has led to this belief that it needs to be littered throughout the majority of the code.

[nathan130200]

Yeah i read post about syncronization context and when to use configureawait in msdocs, they said 99% of time you don't need to use ConfigureAwait manually because compiler will do the best to solve.

[HaloFour]

@nathan130200

they said 99% of time you don't need to use ConfigureAwait manually because compiler will do the best to solve.

The docs certainly shouldn't say that, the compiler doesn't do anything. It doesn't know that ConfigureAwait or SynchronizationContext even exists. You shouldn't need to call ConfigureAwait 99% of the time because you should want to resume on the synchronization context. The percentage will change depending on the type of code you write, and shared library authors might find themselves on the other side of that percentage.

[nathan130200]

My bad, i wrote wrong. I read something like here https://devblogs.microsoft.com/dotnet/configureawait-faq/

[jnm2]

await(...) awaitable is very confusing also, because awaitable can also look like (awaitable): await(expr1)(expr2)

Not that anything is ultimately unresolvable with enough rules, but that it's maybe not a first choice.

[MgSam]

I don't understand how this issue has not even been triaged in an LDM 5 years since being suggested. This is one of the ugliest warts in C#. I can't think of another language where such a critical language feature that developers use dozens of times daily is so crippled as to require such a verbose workaround at every usage.

For developers in the real world writing real code, this feature would be 100X more impactful than 90% of the stuff LDT spends time on. And it's not exactly like its controversial or difficult to implement. Guys, let's get this done already.

[CyrusNajmabadi]

Get someone in a position of authority in the team to review this thread and make a shortlist of community-submitted suggestions that they think are the best, if not outright endorsing them.

What if there are no suggestions that rise to that level?

[daiplusplus]

What if there are no suggestions that rise to that level?

That's a bit defeatist, no?

[CyrusNajmabadi]

How so? All I'm saying is that, so far, no one seems to have a suggestion that really would be suitable.

[foxesknow]

The more async/await work I do the more I find the ConfigureAwait stuff a pain, and you're right, after 5 years it's not good. Still, in that time they did give us a messy implementation of NRT and extension methods :-(

It's just a matter of time until someone tells you to write a code analyzer or source generator to fix the problem...

[HaloFour]

@foxesknow

It's just a matter of time until someone tells you to write a code analyzer or source generator to fix the problem...

If source generators were capable of AOP then I would have, and it's very likely someone would have written one and put it up on NuGet by now. Unfortunately they don't support that, so the best I can do would be to suggest Fody.

[jjxtra]

What about await! or @await or something similar?

[HaloFour]

The use of ConfigureAwait(false) should be in the minority in general, even for libraries intended for use by UI apps. I think the guidance around its use has been overzealous and the deadlock potentials overstated.

You can already make it a lot less verbose via extension methods. You can also temporarily disable the SynchronizationContext making it unnecessary to use it at all.

@MgSam

Check out: #2649

[CyrusNajmabadi]

@await is already legal syntax today.

[jjxtra]

@await will await with configure await of false?

[CyrusNajmabadi]

@jjxtra I'm saying that this is already legal syntax with legal meaning today: @await (foo()). We can't change that.

[jjxtra]

Got it

[nathan130200]

What about to use proposal for reduce null checks verbosity #2145 in await? Like await myCoolTask!!; Or @ at end await myCoolTask@;

For !!
For justify these double !! symbol: "Not in same context", "Avoid same threading context"

[HaloFour]

See: #35

[nathan130200]

I see no problem, is at end of syntax (and currently !! at end is invalid sytax). Also will not conflict with #2145 because !! is on name of variable not in type

[jnm2]

There are future hopes for await foo!! to mean (roughly) await (foo ?? throw new ArgumentNullException(nameof(foo))) when foo is a method parameter.

[qrli]

Rather than playing with await syntax, I think the project level setting (in csproj) raised and vetoed before makes sense now:

• For non-UI library, console, or ASP.NET Core projects, we can set <ConfigureAwait>false</ConfigureAwait>. Then all await behave as ConfigureAwait(false) by default, while opposite behavior can be opted in by ConfigureAwait(true).
• For GUI or GUI component library, legacy ASP.NET projects, we can set <ConfigureAwait>true</ConfigureAwait>. Then all await behave as today, where opposite behavior is opted in by ConfigureAwait(false).

The later will be the default if not defined in csproj, so no breaking existing projects. For new projects, each project template can have a sensible default.

[HaloFour]

Controlling it by a compiler switch would be making it a dialect.

[qrli]

But consider [InternalsVisibleTo(...)], global usings, <LangVersion>, -checked, -nullable, etc.

[HaloFour]

1. InternalsVisibleTo is an attribute, not a project switch.
2. Global usings are defined in code. Implicit usings are an MSBuild feature that automatically generates that code.
3. Each language version is definitely a dialect, but it'd be kinda hard to evolve the language at all without that.
4. Checked is a compiler switch, and considered by the language team to be a mistake.
5. Nullable is the one major exception, but that is to address the "billion dollar mistake" and felt to reach the bar.

If the team were to consider this approach I'd rather they'd take a page from Fody and go with an attribute that could be targeted at the assembly, class or method level. That would give you both the default and the mechanism to override on a granular level. That all assumes that the language team is willing to bake knowledge of TPL synchronization policy into the language, and so far they seem hesitant to do so.

[nathan130200]

Another way, global toplevel exposed to set ConfigureAwait on default task scheduler for all taks (and ability to set in inner task schedulers)

TaskScheduler.Default.InheritContext = false so all nested await calls will pull InheritContext property on current task scheduler (default or nested) and automatically any await task will set true/false on configureawait.

Another option pragmas (like previously said):

#configureawait false
// all await calls will use .ConfigureAwait(false)
#configureawait restore

Or leave .ConfigureAwait(false) since isn't most cases that we must enforces configure await, its just in special cases.

[HaloFour]

Another way, global toplevel exposed to set ConfigureAwait on default task scheduler for all taks (and ability to set in inner task schedulers)

This would break any UI application that relies on that code.

Or leave .ConfigureAwait(false) since isn't most cases that we must enforces configure await, its just in special cases.

This isn't correct, the ratio is the other way around. The majority of application code (which is the majority of code in general) should continue on the synchronization context. That's why the BCL team decided to make that the default behavior.

[TonyValenti]

I create a series of extension methods named "DefaultAwait()" that are specific for that assembly's implementation and call either ConfigureAwait(false) or ConfigureAwait(true). This frees me from having to type ConfiguireAwait(false) and jsut allows me to type the same thing everywhere.

For example:

await DoWork().DefaultAwait();

[jscarle]

I would like to propose something much simpler. Since the Task.ConfigureAwait(Boolean) is only ever called to specify a value of false since the default value is true, and the value is provided statically and defined at compile time in 99.9% of all cases, I propose, like a boolean which has two possible values, that two keywords be used, one for true and one for false. Of course, the ConfigureAwait method would remain for the edge cases where someone would want to specify the value using a variable.

As await Task is already synonymous to await Task.ConfigureAwait(true), then it would be easy to understand that await Task.ConfigureAwait(false) would be synonymous to awaitf.

await Task == await Task.ConfigureAwait(true)
awaitf Task == await Task.ConfigureAwait(false)

That would also allow the compiler team to make further optimizations to the rendered code since you're implicitly and statically defining that you do not want the SynchronizationContext captured.

I see awaitf as a natural extension of the keyword as it fits into the development flow without much effort.

I want to await my task, await.

I want to await my task but I want to configure it as false, awaitf.

It also adds only a single byte to each method. 😉

[CyrusNajmabadi]

the flow is the same, the changes are lightweight. ConfigureAwait() completely destroys that.

This is ultimately subjective. I do async programming for 100% of my coding day job, and I don't even notice CA when reading/maintaining. In projects I work on where it is mandated I simply use the fixer to add it, or I type awaitf and have that expand for me when writing.

Ldm, which is nearly all people who are coding daily, just doesn't view this as a big deal. Maybe a tiny friction point. But one of many in the language. Given that, and absent a realistic proposal, the status quo remains.

[MgSam]

Generally speaking, the creation of dialects that make code harder to understand.

@CyrusNajmabadi You say that and yet you literally just added infinite new dialects into the language via Global Usings... :)

The stated goal the past few years has been to make C# easier to use and more accessible. This is a natural next step. You cannot write modern C# without constantly writing await.

[CyrusNajmabadi]

You say that and yet you literally just added infinite new dialects into the language via Global Usings... :)

We absolutely did not. At the language and compiler level, there is no dialect here. A global using is just source code that must exist in the source the compiler compiles.

This was actually a critical and emphatic part of the design. The initial proposal considered doing this as a dialect and was roundly rejected.

"Implicit usings" are a feature outside of the language. They simply use a source generator to produce normal c# source. So there is no dialect involved.

[CyrusNajmabadi]

This is a natural next step.

There are 1000 next natural steps. :-)

As I've said above, we haven't seen anyone provide a proposal that we felt was acceptable and appropriate. Given that, and the high impact of many other issues that do have proposals to solve them, our attention is on those. :-)

The stated goal the past few years has been to make C# easier to use and more accessible.

Yes, and I think all the work we are doing is in line with that. If a suitable proposal can be made here, we'll definitely triage and consider how that ranks against everything else we're looking at.

[CyrusNajmabadi]

@HaloFour The minutia of how exactly it's implemented or by which team inside Microsoft is not important to me.

But it is important to us. We need an actual solution that we can design and realistically execute on with acceptable costs.

Saying you really want things better here is fine. It's definitely a signal that you care about it and that it's high on your list of concerns. But that doesn't magically translate to a solution. An actual mechanism had to be devised to solve this, and at far no one (internally or externally) had even figured out what that would be.

At the same time, simple options have been made available that do not take the friction to 0, but still drop it greatly. Along with analyzers to help you use those options, this has can't sufficient to us.

You may choose to not take those existing options. And you may certainly feel that any friction here is not acceptable. But that is ultimately your own choice and doesn't reflect how we view things.

[msarangdhar]

This thread certainly saved me! The whole async/await pattern is great except it was probably built with "let me be helpful managing the context switching for you" - with no regard to the various environments/libraries it may have to be used in. The ConfigureAwait pattern just seems like an after thought.

Is there a facility for dependency injection or overrides to have your own custom context in your library through a Provider pattern?