Clearly indicate calls to async functions in synchronous context by introducing a 'sync' keyword

[ramayasket]

The problem
Let's define a function async object MyFunc(). In an asynchronous context, we have the await keyword to get its result:
object x = await MyFunc();
Because of this keyword, it is clearly visible that MyFunc is asynchronous, which helps understand the code.
Now in a synchronous method, there is no await, and a call will look like this:
object x = MyFunc().Result;
The problem here is that .Result follows exactly the same notation most public class member names follow - Pascal, separated by dots. So this .Result naturally mixes with all the names to the left of it, thus making it SLOWER to recognize the async nature of MyFunc. To indicate this nature, the practice is to add the Async suffix to a function name. In total, a typical synchronous syntax would be:
object x = MyFuncAsync().Result;

The idea
It is suggested to introduce a sync keyword so the above call is rewritten as follows:
object x = sync MyFunc();
Very similar to:
object x = await MyFunc();
For a function returning non-typed Task, the sync keyword would translate to a Wait() call.

Benefits

• the code is shorter so the cognitive load to read it is reduced
• a clearer indication that MyFunc is asynchronous
• more consistent syntax for asynchronous vs synchronous contexts: await vs sync, and not yet another Pascal term
• different keywords for asynchronous and synchronous contexts: helps keep track of where we are

[HaloFour]

I don't see the utility in writing a synchronous method in such a manner. It's not a coroutine, so there's no language support required in order to yield execution. You can already block manually via the methods provided by the task.

Manually blocking a Task is also generally considered bad practice as it could lead to deadlocks with synchronization. The language shouldn't make it easier to write such code.

[ramayasket]

See my reply below

[ramayasket]

You can already block manually via the methods provided by the task.

That's right, but this syntax looks ugly, and does not indicate clearly that the function called is asynchronous, as with await.
The suggested keyword is only a syntax sugar around .Result and the async nature of the function is clearly visible.

considered bad practice

In a non-async context, .Result is the only practice to execute a task and get its result. So let it just look nice.

[HaloFour]

I disagree that it looks ugly. It looks like normal code, as all normal code is synchronous and blocks. There's no need to make it look different, especially with a goal to make it seem symmetric with asynchronous code as they are incredibly different forms of execution and shouldn't feel the same.

[ramayasket]

Ok, let me explain what I mean by ugly. From your reply I understand that ugly isn't the best word.

Let's get back to this call: object x = await MyFunc();

This code answers two fundamentally different questions:

• what am I doing?
• what framework is doing for me?

MyFunc is the first answer, await is the second. They are clearly distinct - separated by space, 1st PascalCase, 2nd lowercase. This distinction makes them easy to recognize while reading the code.

Now in a non-async context: object x = MyFunc().Result;. Here, 1st and 2nd answers are mixed and difficult to distinguish - they are in the same case, and separated by dot, which is typical to the 1st question. Imagine a realistic call like this:

var items = Storage.Query<Item>().Select().Result;

Here goes 3 terms of my intentions and 1 term of framework details, and mind must make an effort to recognize the 4th term as framework-specific. This initial confusion is the reason for the change. Adding the sync keyword is aimed at separating author's intentions and framework spec once again, similarly to how it's done in async/await.

var items = sync Storage.Query<Item>().Select();

[HaloFour]

They're all framework details. The question is what is the language doing for you, and in terms of normal method invocation, that is absolutely nothing.

That's even ignoring the fact that this pattern should not be encouraged by the language because it is almost always the wrong thing to do.