Why is the call ambiguous? 'Task.Run(Action)' and 'Task.Run(Func)'

Clash Royale CLAN TAG#URR8PPP

up vote
23
down vote

favorite

1

Considering the following code:

public void CacheData()

 Task.Run((Action)CacheExternalData);
 Task.Run(() => CacheExternalData());

 Task.Run(CacheExternalDataTask);

 Task.Run(CacheExternalData);


public Task CacheExternalDataTask()

 // Long running code
 return Task.FromResult("Data");


public void CacheExternalData()

 // Long running code

Why is Task.Run(CacheExternalData) ambiguous? And Task.Run(CacheExternalDataTask) is not?

When calling Task.Run with CacheExternalData I would have thought it was clear to the compiler that the method does not return a Task and it should resolve to an Action?

c# task

share|improve this question

edited Aug 14 at 13:52

Boann

35.6k1184116

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

add a comment | 

up vote
23
down vote

favorite

1

Considering the following code:

public void CacheData()

 Task.Run((Action)CacheExternalData);
 Task.Run(() => CacheExternalData());

 Task.Run(CacheExternalDataTask);

 Task.Run(CacheExternalData);


public Task CacheExternalDataTask()

 // Long running code
 return Task.FromResult("Data");


public void CacheExternalData()

 // Long running code

Why is Task.Run(CacheExternalData) ambiguous? And Task.Run(CacheExternalDataTask) is not?

When calling Task.Run with CacheExternalData I would have thought it was clear to the compiler that the method does not return a Task and it should resolve to an Action?

c# task

share|improve this question

edited Aug 14 at 13:52

Boann

35.6k1184116

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

add a comment | 

up vote
23
down vote

favorite

1

up vote
23
down vote

favorite

1

1

Considering the following code:

public void CacheData()

 Task.Run((Action)CacheExternalData);
 Task.Run(() => CacheExternalData());

 Task.Run(CacheExternalDataTask);

 Task.Run(CacheExternalData);


public Task CacheExternalDataTask()

 // Long running code
 return Task.FromResult("Data");


public void CacheExternalData()

 // Long running code

Why is Task.Run(CacheExternalData) ambiguous? And Task.Run(CacheExternalDataTask) is not?

When calling Task.Run with CacheExternalData I would have thought it was clear to the compiler that the method does not return a Task and it should resolve to an Action?

c# task

share|improve this question

edited Aug 14 at 13:52

Boann

35.6k1184116

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

Considering the following code:

public void CacheData()

 Task.Run((Action)CacheExternalData);
 Task.Run(() => CacheExternalData());

 Task.Run(CacheExternalDataTask);

 Task.Run(CacheExternalData);


public Task CacheExternalDataTask()

 // Long running code
 return Task.FromResult("Data");


public void CacheExternalData()

 // Long running code

Why is Task.Run(CacheExternalData) ambiguous? And Task.Run(CacheExternalDataTask) is not?

When calling Task.Run with CacheExternalData I would have thought it was clear to the compiler that the method does not return a Task and it should resolve to an Action?

c# task

share|improve this question

edited Aug 14 at 13:52

Boann

35.6k1184116

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

share|improve this question

share|improve this question

edited Aug 14 at 13:52

Boann

35.6k1184116

edited Aug 14 at 13:52

Boann

35.6k1184116

edited Aug 14 at 13:52

Boann

35.6k1184116

35.6k1184116

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

asked Aug 14 at 9:08

Tom.Bowen89

4,24921437

4,24921437

add a comment | 

add a comment | 

1 Answer
1

active

oldest

votes

up vote
25
down vote



accepted

It should be clear, but the language specification never said that mismatched return types would have any effect during overload resolution. Because of that, there was no rule that said to prefer Action over Func<Task>. If Action would be picked, sure, it would work. If Func<Task> would be picked, then sure, you'd get an error. But to pick either, overload resolution has to succeed, and it isn't taking this into account.

This is supposed to be fixed with new overload resolution in C# 7.3.

share|improve this answer

answered Aug 14 at 9:16

hvd

112k11191270

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
  – Marc Gravell♦
  Aug 14 at 9:18
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  It was a pretty obvious bug in the specification.
  – Joshua
  Aug 14 at 17:25
  

  
  
  
  

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51837722%2fwhy-is-the-call-ambiguous-task-runaction-and-task-runfunctask%23new-answer', 'question_page');

);

Post as a guest

Name Email

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
25
down vote



accepted

It should be clear, but the language specification never said that mismatched return types would have any effect during overload resolution. Because of that, there was no rule that said to prefer Action over Func<Task>. If Action would be picked, sure, it would work. If Func<Task> would be picked, then sure, you'd get an error. But to pick either, overload resolution has to succeed, and it isn't taking this into account.

This is supposed to be fixed with new overload resolution in C# 7.3.

share|improve this answer

answered Aug 14 at 9:16

hvd

112k11191270

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
  – Marc Gravell♦
  Aug 14 at 9:18
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  It was a pretty obvious bug in the specification.
  – Joshua
  Aug 14 at 17:25
  

  
  
  
  

add a comment | 

up vote
25
down vote



accepted

It should be clear, but the language specification never said that mismatched return types would have any effect during overload resolution. Because of that, there was no rule that said to prefer Action over Func<Task>. If Action would be picked, sure, it would work. If Func<Task> would be picked, then sure, you'd get an error. But to pick either, overload resolution has to succeed, and it isn't taking this into account.

This is supposed to be fixed with new overload resolution in C# 7.3.

share|improve this answer

answered Aug 14 at 9:16

hvd

112k11191270

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
  – Marc Gravell♦
  Aug 14 at 9:18
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  It was a pretty obvious bug in the specification.
  – Joshua
  Aug 14 at 17:25
  

  
  
  
  

add a comment | 

up vote
25
down vote



accepted

up vote
25
down vote



accepted

It should be clear, but the language specification never said that mismatched return types would have any effect during overload resolution. Because of that, there was no rule that said to prefer Action over Func<Task>. If Action would be picked, sure, it would work. If Func<Task> would be picked, then sure, you'd get an error. But to pick either, overload resolution has to succeed, and it isn't taking this into account.

This is supposed to be fixed with new overload resolution in C# 7.3.

share|improve this answer

answered Aug 14 at 9:16

hvd

112k11191270

It should be clear, but the language specification never said that mismatched return types would have any effect during overload resolution. Because of that, there was no rule that said to prefer Action over Func<Task>. If Action would be picked, sure, it would work. If Func<Task> would be picked, then sure, you'd get an error. But to pick either, overload resolution has to succeed, and it isn't taking this into account.

This is supposed to be fixed with new overload resolution in C# 7.3.

share|improve this answer

answered Aug 14 at 9:16

hvd

112k11191270

share|improve this answer

share|improve this answer

answered Aug 14 at 9:16

hvd

112k11191270

answered Aug 14 at 9:16

hvd

112k11191270

answered Aug 14 at 9:16

hvd

112k11191270

112k11191270

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
  – Marc Gravell♦
  Aug 14 at 9:18
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  It was a pretty obvious bug in the specification.
  – Joshua
  Aug 14 at 17:25
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  8
  

  
  
  
  
  
  

  
  To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
  – Marc Gravell♦
  Aug 14 at 9:18
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  It was a pretty obvious bug in the specification.
  – Joshua
  Aug 14 at 17:25
  

  
  
  
  

8

8

To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
– Marc Gravell♦
Aug 14 at 9:18

To confirm: yes, it is fixed in 7.3; adding <LangVer>7.3</LangVer> to a test project makes it resolve correctly
– Marc Gravell♦
Aug 14 at 9:18

1

1

It was a pretty obvious bug in the specification.
– Joshua
Aug 14 at 17:25

It was a pretty obvious bug in the specification.
– Joshua
Aug 14 at 17:25

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51837722%2fwhy-is-the-call-ambiguous-task-runaction-and-task-runfunctask%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email