Skip to content
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

Signature of methods with default CancellationToken are generated incorrectly with null default value #390

Open
divega opened this issue Nov 30, 2018 · 4 comments

Comments

@divega
Copy link

divega commented Nov 30, 2018

This was previously reported at dotnet/EntityFramework.ApiDocs#25, specifically for methods that contain cancelationToken = default, which is a really common pattern,but it could apply to other defaults, not sure.

From the original issue:

In https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.dbcontext.savechangesasync?view=efcore-2.1 it says signature for SaveChangesAsync is

    public virtual System.Threading.Tasks.Task<int> SaveChangesAsync (
        System.Threading.CancellationToken cancellationToken = null);

Obviously, if you try overriding SaveChangesAsync using the above example, it'll give you the following error:

Using default(CancellationToken) instead of null solves the issue:
public override async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default(CancellationToken))

In fact the original signature is:

    public virtual Task<int> SaveChangesAsync(
        CancellationToken cancellationToken = default)

cc @joelmartinez

@joelmartinez
Copy link
Member

So this seems to be a compiler-level thing … the assembly metadata doesn't seem to (afaik) give any indication when the user-supplied value for the parameter is null vs default.

I guess the question here is whether for C# signatures, should we switch to using default for all of these instances, rather than using null.

@dend, thoughts?

@roji
Copy link

roji commented Aug 28, 2019

Ran into this again, hopefully someone can take a look at some point.

@joelmartinez
Copy link
Member

Hi @roji ... this definitely has not been forgotten. In fact, there's an internal issue (linking it here just for reference). I don't have an exact ETA, but it will definitely be resolved at some point :)

@roji
Copy link

roji commented Aug 28, 2019

Thanks @joelmartinez!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants