-
Scenario 1: I have my own declaration of SelectListItem and if i try this:
I get ambiguous error because in my MVC app is another class with same name (https://msdn.microsoft.com/en-us/library/system.web.mvc.selectlistitem(v=vs.118).aspx) I'm forced to use the entire namespace path explicit like this:
Is not obvious and sufficient if i have Scenario 2: If i have this explicit variable declaration also i'm forced to use all namespace when i initialize this variable:
Why not using like this:
|
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
You can make the existing case a bit simpler by namespace aliases.
Also note the usage of var instead of explicit type, which simplifies things for your second scenario. |
Beta Was this translation helpful? Give feedback.
-
Well, but what should happen in the following setup:
? I'd better prefer target-typed
|
Beta Was this translation helpful? Give feedback.
-
@vladd YES, this should be much better, elegant and simple way. |
Beta Was this translation helpful? Give feedback.
-
No, it is not. You may be referencing another type with that same name from some other namespace. Code like this already may exist today. We can't break the meaning of it. |
Beta Was this translation helpful? Give feedback.
-
If I have the same name from same other namespace then I can get the ambiguous error. |
Beta Was this translation helpful? Give feedback.
-
Even better is what ReSharper suggests and I'm hoping Roslyn soon suggests out of the box (dotnet/roslyn#23373): using SelectListItem = Base.Models.Metadate.SelectListItem;
// ...
var my = new List<SelectListItem>
{
new SelectListItem()
} With the championed target-typed var my = new List<Base.Models.Metadate.SelectListItem>
{
new()
} |
Beta Was this translation helpful? Give feedback.
-
In c# 9 this will be possible using Target-typed new expressions 👍 |
Beta Was this translation helpful? Give feedback.
In c# 9 this will be possible using Target-typed new expressions 👍