Resolve enum references more smartly

[gafter]

From @omidkrad on September 16, 2015 0:20

Example:

new System.Transactions.TransactionOptions
{
    IsolationLevel = IsolationLevel.ReadCommitted
}

Gives Error:

CS0104 'IsolationLevel' is an ambiguous reference between 'System.Transactions.IsolationLevel' and 'System.Data.IsolationLevel'

When we know TransactionOptions.IsolationLevel property is of type System.Transactions.IsolationLevel then we have all we need to disambiguate the references.

I think we should be able to even do the following without any using namespace or using static:

new System.Transactions.TransactionOptions
{
    IsolationLevel = ReadCommitted
}

This could apply to types other than Enum as well.

Copied from original issue: dotnet/roslyn#5262

[gafter]

From @GSPP on September 21, 2015 8:3

This would be very handy. I think this should be split into two proposals:

1. Allow IsolationLevel = ReadCommitted.
2. Allow IsolationLevel = IsolationLevel.ReadCommitted.

(1) is a more radical.

(1) also should work in any case where there is an assignment (or something like it) to an enum type. For example, variables and method call arguments. It should not be restricted to object initializers.

[gafter]

There are other contexts where this is desired - for example, in the case constants when switching on an enum. See #952.

[gafter]

From @omidkrad on November 21, 2015 2:22

@gafter another case is when passing enum parameters to methods.

[gafter]

@omidkrad I don't have an idea how to do that sanely in the presence of overloading.

[gafter]

From @omidkrad on November 23, 2015 18:28

@gafter how about with named parameters only?

[gafter]

@omidkrad How do "named parameters" help?

[gafter]

From @omidkrad on November 23, 2015 19:6

@gafter You have their type information. I mean for example:

using System.Transactions;
using System.Data;

void Main()
{
    // resolve System.Transactions.IsolationLevel.ReadCommitted 
    CreateTransactionOptions(isolationLevel: ReadCommitted);
}

TransactionOptions CreateTransactionOptions(System.Transactions.IsolationLevel isolationLevel)
{
    return new System.Transactions.TransactionOptions
    {
        IsolationLevel = isolationLevel
    };
}

[gafter]

@omidkrad Sometimes. And sometimes the named parameters still leave you with multiple overloads to select from. Taking named parameters into account doesn't help us figure out what to do in the language specification or compiler, as such cases still need to be handled.

[gafter]

From @omidkrad on November 23, 2015 21:45

I guess that should produce a conflict error. Just like in PowerShell you can use part of the parameter name instead of the full parameter name. If it cannot resolve, it will give you an error. example:

> dir -f
Get-ChildItem : Parameter cannot be processed because the parameter name 'f' is ambiguous. Possible matches include:
-Filter -Force.`

[gafter]

@omidkrad Yes; I propose that if an identifier does not resolve when used as an argument in a method call, we look no further (i.e. we don't try to perform overload resolution, even if there is only a single method) and just report the error.

[gafter]

From @omidkrad on November 23, 2015 23:56

@gafter agreed.

[DavidArno]

@gafter,

Whilst recreating these old threads here is highly commendable, the way you mix quotes from old threads with your own comments being unquoted, makes them hard to read. Would it be possible to put some sort of big "START OF RECREATED THREAD" and "END OF RECREATED THREAD" markings in them, for folk like me who are hard of reading at times?

[alrz]

I think comments are better off in the original issue (as they always will). We still have links to the original thread.

[jnm2]

@DavidArno @alrz I'm used to people using extensions do do this; it's standard practice all over the place on GitHub. GitHub doesn't have a great built-in feature for transplanting conversations. (@haacked)

[Thaina]

Sadly this issue has no milestone yet