[This post is part of a series, “wish-list for future versions of VB“]
IDEA: Allow unambiguous types from ambiguous namespaces. This request arises from VB’s powerful “import” feature, which is more flexible than that of C#, but which introduces problems. I’ll explain by example:
Dim x As ComponentModel.INotifyPropertyChanged
‘ In Winforms apps, this is ambiguous
‘ between System.ComponentModel and System.Windows.Forms.ComponentModel
If you write this code in a Console app then it compiles fine. But if you write it in a Winforms app then it’s a compile-time ambiguity error. That’s because Winforms apps import both “System” and “System.Windows.Forms”, and the compiler doesn’t know whether the prefix “ComponentModel” means System.ComponentModel or System.Windows.Forms.ComponentModel.
It makes VB fragile against the framework introducing new types or namespaces.
IDEA: VB should allow “X.Y.Z” whenever the full name “X.Y.Z” is unambiguous (even if the prefix “X.Y” is ambiguous).
Here are some other examples:
‘ In WPF aps, this is ambiguous
‘ between System.Threading and System.Windows.Threading
Dim y As Xml.Linq.XDocument
‘ If you import System.Security.Cryptography, this is ambiguous
‘ between System.Xml and System.Security.Cryptography.Xml
It’s not clear if this idea should work for ambiguous namespace and class prefixes, or merely for ambiguous namespace prefixes.
Provisional evaluation from VB team: We agree that this is a problem that would be good to fix. However, the spec rules for “unqualified and qualified name lookup” are already baffling ($4.7 and $11.4.4). This proposal would complicate them yet further. We will only consider this if we get clear and unambiguous feedback from users that they want the feature.