Consider providing a keyword to leak variable scopes.

[taori]

I've got some code which depends on the result of 3 web requests. The following code could be much more brief if there was a way to let variables leak.

if there were a keyword with that functionality i could turn all that code into something like this:

Current

public class CurrentSyntaxSyntax
{
	public async Task Execute(CancellationToken cancellationToken, int currentServiceProgramId, int currentSiteId)
	{
		var spiRep = new ServiceProgramInfoRepository(null);
		var psiRep = new ProjectStructureInfoRepository(null);
		var psspRep = new ProjectStructureServiceProgramRepository(null);

		var spiTask = ResponseRepeater.RepeatUntilSuccessAsync(() => spiRep.GetBySpAndSiteAsync(QueryType.PreferStorage, currentServiceProgramId, currentSiteId), cancellationToken);
		var infoFieldTask = ResponseRepeater.RepeatUntilSuccessAsync(() => psiRep.GetBySiteIdAndSpIdAsync(QueryType.PreferStorage, currentSiteId, currentServiceProgramId), cancellationToken);
		var psspTask = ResponseRepeater.RepeatUntilSuccessAsync(() => psspRep.GetBySiteIdAsync(QueryType.PreferStorage, currentSiteId), cancellationToken);

		await Task.WhenAll(spiTask, infoFieldTask, psspTask);

		ProcessResults(spiTask.Result, infoFieldTask.Result, psspTask.Result);
	}

	private void ProcessResults(RepositoryResponse<List<ServiceProgramInfoV1>> spiTaskResult, 
		                        RepositoryResponse<List<ProjectStructureInfoV1>> result, 
		                        RepositoryResponse<List<ProjectStructureServiceProgramV1>> psspTaskResult)
	{
		// do something with the results.
		throw new NotImplementedException();
	}
}

Suggestion

public class SuggestedSyntax
{
	public async Task Execute(CancellationToken cancellationToken, int currentServiceProgramId, int currentSiteId)
	{
		var spiRep = new ServiceProgramInfoRepository(null);
		var psiRep = new ProjectStructureInfoRepository(null);
		var psspRep = new ProjectStructureServiceProgramRepository(null);

		await Task.WhenAll(
			declare var spiTask = ResponseRepeater.RepeatUntilSuccessAsync(() => spiRep.GetBySpAndSiteAsync(QueryType.PreferStorage, currentServiceProgramId, currentSiteId), cancellationToken),
			declare var infoFieldTask = ResponseRepeater.RepeatUntilSuccessAsync(() => psiRep.GetBySiteIdAndSpIdAsync(QueryType.PreferStorage, currentSiteId, currentServiceProgramId), cancellationToken),
			declare var psspTask = ResponseRepeater.RepeatUntilSuccessAsync(() => psspRep.GetBySiteIdAsync(QueryType.PreferStorage, currentSiteId), cancellationToken)
		);

		// spiTask, infoFieldTask, psspTask useable at this point.

		ProcessResults(spiTask.Result, infoFieldTask.Result, psspTask.Result);
	}

	private void ProcessResults(RepositoryResponse<List<ServiceProgramInfoV1>> spiTaskResult, 
		                           RepositoryResponse<List<ProjectStructureInfoV1>> result, 
		                           RepositoryResponse<List<ProjectStructureServiceProgramV1>> psspTaskResult)
	{
		// do something with the results.
		throw new NotImplementedException();
	}
}

Using Task.WhenAll always feels rather awkward if you need to combine the results of parallel requests - with a keyword to leak those varibles to the outer scope, that would be a non issue.

[YairHalberstadt]

It's a little tricky to see what you are asking for.

Instead of using a picture, could you write a minimal example, showing what you currently have to do, and what you would like to have added to the language.

A little bit of explanation about the semantics of the feature, advantages, disadvantages, alternatives etc. always does help, but is not critical.

[HaloFour]

You're free to declare variables in the outside scope and then assign them within the lambda.

Also, https://www.nuget.org/packages/TaskTupleAwaiter/

[taori]

You're free to declare variables in the outside scope and then assign them within the lambda.

That is correct. However think of int.TryParse - never in my life would i want to go back to declaring variables ahead of time just to use them. It is a minor syntax difference, but the quality of life improvement when writing the code is significant.

I'll have a look at the package though, thanks.

[taori]

It's a little tricky to see what you are asking for.

I purposely used an image here, to point out how much more convenient the later syntax would be, if it were to exist the way i would imagine it.

[taori]

@HaloFour

Also, https://www.nuget.org/packages/TaskTupleAwaiter/

using the new Value Tuple structure to write elegant code that allows async methods to be fired in parallel despite having different return types

If that is true that package description is true, that perfectly solves my requirement, thanks - however it would be great if this were a language feature too, so everyone could benefit from it.

[YairHalberstadt]

@taori
I understand that you purposefully used an image.

Nonetheless adding a minimal text example does make it easier for most people to quickly understand what you want.

[taori]

@taori
I understand that you purposefully used an image.

Nonetheless adding a minimal text example does make it easier for most people to quickly understand what you want.

Fair enough. I'll add some sample code. Thanks for the suggestion.

[HaloFour]

If that is true that package description is true, that perfectly solves my requirement, thanks - however it would be great if this were a language feature too, so everyone could benefit from it.

The language feature is that everything is awaitable, as long as someone provides the correct API. The language only cares that it can resolve a GetAwaiter method on whatever it is that you're trying to await and that the return value of GetAwaiter follows the expected pattern. That's how the NuGet package is able to provide that functionality.

There was a proposal to add these APIs to the BCL, but unfortunately that was closed: https://github.com/dotnet/corefx/issues/16010

[taori]

If that is true that package description is true, that perfectly solves my requirement, thanks - however it would be great if this were a language feature too, so everyone could benefit from it.

The language feature is that everything is awaitable, as long as someone provides the correct API. The language only cares that it can resolve a GetAwaiter method on whatever it is that you're trying to await and that the return value of GetAwaiter follows the expected pattern. That's how the NuGet package is able to provide that functionality.

There was a proposal to add these APIs to the BCL, but unfortunately that was closed: dotnet/corefx#16010

Yeah. i found a blog mentioning this a year back or so. Too bad i never came up with using it like this. That sure is a damn amazing way of doing Task.WhenAll. Very grateful for you sharing this with me :)

Very sad it didn't make it into BCL

[svick]

There's also a proposal to add awaiting a tuple of tasks directly to C#: #380 (though it doesn't seem likely it will be accepted anytime soon).

[yaakov-h]

Wouldn’t Declaration Expressions (#595) cover this particular case?

[dsaf]

The best keyword to re-use for leaking would be unsafe:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/unsafe

[taori]

Wouldn’t Declaration Expressions (#595) cover this particular case?

Actually it very much looks like this request would be fulfilled if #595 were implemented, yes.

[MkazemAkhgary]

When you have this

var func = (Action<int>) x => { declare var y = x; }
if(cool) func(3);
Console.WriteLine(y);

How are you going to guarantee that func is called before reading y? if its not called, then variable is not initialized.

---

Something like this could work but i'm not a fan :)

var func = (Action<int>) x => { declare var y = x default 0; }

Also leak by how much?

{
    {
        {
            declare var x = ...;
        }
    }
}
// is x accessible here?

[taori]

When you have this

var func = (Action<int>) x => { declare var y = x; }
if(cool) func(3);
Console.WriteLine(y);

How are you going to guarantee that func is called before reading y? if its not called, then variable is not initialized.

Something like this could work but i'm not a fan :)

var func = (Action<int>) x => { declare var y = x default 0; }

To be honest that is a case i did not even think of. While i think the feature would be nice to have, i am not quite sure how the feature would even work if you can't make sure the expression which would declare a variable is called before the code which uses it.

Also leak by how much?

{
    {
        {
            declare var x = ...;
        }
    }
}
// is x accessible here?

I would say no. it should only link to the same level the statement is declared on.