This project is read-only.
2
Vote

Alternatives to Dim for variables

description

Dim seems to be a holdover from ancient history, and new users of VB would naturally expect it to be related to the ReDim keyword, and to have something to do with Arrays.

I think the Let keyword would make more sense for non-array variables, and this would even match the spirit of the way Let is already used. (In the Let Query Operator to introduce an expression range variable). Section 11.21.6 of the VB spec even uses Dim to explain what Let means.
"...
Let tax = o.Price * 0.088... can be thought of as equivalent to ...
Dim tax = o.Price * 0.888
..."

<yoda>Backwards thinking seems that to me</yoda>

Instead I would like to teach new users that "Dim" can be thought of as "Let", because "Let" is more intuitively obvious in its meaning.

I also think that Declare would be a better alternative keyword to Dim sometimes, because before type inference we often wrote...
Dim a As Double
where...
Declare a As Double
would be a more intuitively obvious syntax.

Maybe the grammar could handle both Declare and Let as aliases for Dim without being ambiguous?

comments

AdamSpeight2008 wrote Dec 4, 2014 at 3:13 AM

Dim could stand for Declare In Memory. Let is also used in Query Syntax in LINQ, should there could be a clash. I don't see how having two way to declare a variables would be "better" then the current keyword? To me as a learner it would be more confusing.

ADGreen wrote Dec 5, 2014 at 1:43 AM

Hey Justin,

I'm assuming you're the same J Michel that filed this user voice request (http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3940543-let-as-an-alternate-for-dim) If not, that's an amazing coincidence :)

First, let me say – I 100% agree with you, and I know of a few other VB developers (including VB team members) who also share a dis-favorable sentiment from time to time though it’s not at all the prevailing inclination. Wonderfully despite various changes in the language to introduce new places to declare variables (For, For Each, From, Catch) no Visual Basic team has ever expanded the number of places Dim can be used. Working on Roslyn we build up a lot of immutable data structures that require declaring a lot of intermediate temp variables and after writing Dim a dozen or more times I start to feel a little dim myself :) I’m very proud of the fact that almost every keyword in a VB program means something as I read it out loud and Dim doesn’t intuitively mean anything (though I understand how historically it drifted into its current meaning, much as words in natural languages change meaning over time). As a language that’s supposed to be approachable for beginners and readable to even non-programmers it’s a shame that this very common construct doesn’t read more naturally.

That said, I’m afraid this just may be pain we’ll have to live with. I’m a big believer that languages don’t get a lot of “do-overs”. And for one reason or another we’ve seen a lot of requests over the years to do something over a different way from how VB has it, for example:
  • Shared classes instead of modules
  • An alternative casting syntax
  • A different prefix for hexadecimal literals
  • A shorter lambda expression syntax
  • A Dynamic type instead of late-binding to Object
  • Different syntax for assignment and comparison
  • A different way to express null than Nothing
  • A different syntax for Indexing into an array vs invoking a method
  • A different array declaration syntax (by size rather than bounds)
  • A different way to declare local variables.
    ...The list goes on...
And don’t get me wrong, often I can appreciate the small gain in each individual case but in the aggregate if we redid everything in VB differently three things would result. First, we’d spend less time enabling new scenarios for VB developers (like Async/Await) or "Roslyn" because we’d instead be spending time redoing things that already work. Second, we’d fracture the VB community with one part using these constructs and another using different constructs – there a millions of Dims already out in the world and everyone would have to deal with it and there’d be at least two ways to do anything in VB (not very good for beginners). And lastly, VB would lose a lot of credibility as a coherent language with an intentional and thought out style (which it is, btw); at some point when you have something and you change 80% of it you have to admit that you never really wanted the thing you started with. That’s not to say I don’t think we’ll ever provide an alternate syntax for anything, only that it’s something that should be done very very very very very rarely and with pretty compelling wins.

But back to your specific suggestion. I’ve thought about Let and I like Let for the reasons you mention. I’ve even got a prototype of the compiler somewhere Let can be used for this. And I think the historical usage of Let in BASIC as the assignment statement also lends a lot to Let. But aside from the reasons in the long paragraph above about how we don’t generally do do-overs, there are other factors which give me pause. Let has also gotten pretty popular in other languages with slightly different meanings. JavaScript (EcmaScript 6, I think) introduces let as an alternative to ‘__var__’ meaning block scoped variable rather than global or function scoped variable. F# uses let to introduce a number of different declarations. Apple Swift uses let to declare read-only variables but also inline declarations. We’ve bandied the idea back in forth of also doing read-only local variables in VB or C# and it’s not clear if we’d use Let or ReadOnly vs Dim or Val and Var (like scheme) and then C# might go for ‘__let__’ and then maybe ‘__let__’ means something different in the two languages (which is unpleasant, but, for the record isn’t necessarily a deal breaker) or we might instead use “__Let__” to introduce inline declaration expressions or something. The point is – the term Let is a bit too up in the air right now in the broader and even more local programming community to rush to even the proposal of locking it into just introducing local variable declarations right now (if we were even willing to consider it at all).

But fret not, there is yet hope. You see, technically Dim isn’t “the way you declare variables in VB”. Variables in VB are just introduced by any modifier (Private, Shared, ReadOnly, WithEvents, Const, Static) and Dim is just “a modifier”. It’s a nonspecific placeholder modifier one can use when there are no other modifiers available. In fact if you have another modifier the IDE will usually pretty-list it away as it is redundant. The language spec actually doesn’t even talk about the Dim keyword at all other than listing it as a LocalDeclarationModifier or MemberVariableDeclarationModifier and everything else just falls out of that. It’s not even defined in what way it modifies anything. My point is, if we ever discover another modifier that seems meaningful or useful – most likely in the course of pursuing some other productive venture - you won’t need to use Dim anymore just by the existing rules of the language, at least in any place where that new modifier is as good or better. And then all of us in the resistance can privately celebrate our small victory. Until then, carpe dim, quam minimum credula postero…

Regards,

Anthony D. Green, Program Manager, Visual Basic and C# Languages Team

P.S. We can’t just have variable declarations work without any modifier at all for various reasons including error recovery and the existing syntax for type inference.
P.P.S. No, that was not a typo in the Latin.

justinmichel wrote Dec 5, 2014 at 10:53 PM

Latin puns? Good job, now this site is banned in China. ;)

Yes, the UserVoice was me, but I think I made the argument better here (and actually forgot about the UserVoice item completely.)

Thanks for taking the time to reply.

RobertEinhorn wrote Apr 22, 2015 at 6:38 PM

Hey Anthony,

I suggest only the Declare keyword with a good IDE support.

Declare a As Double
Declare i As Integer = 1
Declare intArray() As Integer = {0, 1, 2, 3}
Declare tax = o.Price * 0.088

IDE support:
  • simpler complete-word by IntelliSense to insert a Declare keyword (D TAB TAB)
  • automatic keyword conversion by IntelliSense from Dim to Declare while typing
  • and of course an automatic old file conversion
Finally, the status of the Dim reserved keyword would be retained, but it would not be longer used in Visual Basic.

related websites:
http://www.i-programmer.info/programming/visual-basic/922-in-praise-of-vb.html

http://stackoverflow.com/questions/1033507/what-does-dim-stand-for-in-visual-basic-and-basic

Regards,
Robert