Quote Originally Posted by Niya View Post
Well that's the thing, there is no ambiguity with type inference. When we see something like:-
Code:
Dim x = 100
We know exactly what type x is because we how the VB.Net compiler behaves. It defaults to a 32 bit Integer. It's no different than a VB6 programmer reading this:-
Code:
Dim x
And knowing that's a Variant. I don't see how it's ambiguous.

I could even argue that in VB6 Dim x is more ambiguous because of Def[type] A-Z statements but no one complains about that.
So then the behavior of VB.NET is different? Const x = 100 in VB6 type inference rules would make that an Integer (VB6 Integer, 16bit signed). And you know what I meant by ambiguous, that it's not readily apparent and you have to dig into a complex rule set, *just like with VB6 Variant typing or consts*, which have resulted in untold hours running down hard to trace bugs, *because of the ambiguity*, and how unneccessarily easy it makes it for people, especially the beginners and people just trying to make quick tools for their actual work, BASIC is popular with.