That's not really a good point at all and your example of using $v1 is especially bad as it's identical to the much older $Ifmatch. $v2 would've been better :p
mIRC had a shorter release cycle when $v2 was introduced, and more people were on the latest version. Now we have many users on older versions (6.35 especially, given the unicode issues some users have) and mIRC has matured and the cycle slowed down, so it's not as easy to be as reckless. Yes, it's the scripter's choice to care about backwards compat, but the language shouldn't intentionally make it more difficult to make these decisions, especially information like when a switch was introduced on a command are slightly more obscured and harder to track. There were also fewer versions to deal with back-compat on. Also, $v1/$v2 wasn't strictly necessary either, and I'm not sure I would have supported it had I been active on the forums then, but again, 10 years ago was a different time for mIRC-- more delta is expected in a young codebase. mIRC isn't young anymore, priorities should shift to favouring more stability unless there is a significant advantage to a new behaviour.
The argument that /set can already do these things became somewhat invalid when /var -g was added.
No, my silence on /var -g should not be interpreted as acceptance of it. I'm no fan of that switch either. Sure, it's too late for that one, but hopefully we can stop the feature creep before it gets any worse.
Again, not sure why a simple and reasonable request is receiving such opposition.
I made it fairly clear why I "oppose" this request. It's easy to say "it's a small change, it will barely have any impact, so there's no reason to oppose it", but at the same time, it's small features like this that end up causing major bloat in languages/APIs down the line. Therefore, I don't judge a feature by how simple it is, but how useful it is. In my mind, a one line change is equal to a one thousand line change in terms of whether,
in my opinion, it should be added.
As it stands, I don't see an apparent real world use case for something like this that extends beyond maybe 1 usage per ~1kLoC, generously. And that's for /var -g in general. How often does a script really need to set multiple global vars at once? In initialization, sure, possibly. Other than that? (Note: this would have been my argument to /var -g in the first place). Also, given that the convention of setting global vars is to prefix them with a scriptname, setting multiple %myscript.foo = somevalue, %myscript.bar = someothervalue doesn't even seem practical, since you end up with a ton of text on a single line-- certainly not more readable. And yet, all of this is again just for /var -g. /var -gu would probably be orders of magnitude less common. If you're only setting multiple global vars once or twice in the duration of a script, how many of those will really need -u? /set -u in itself is already fairly uncommon, and initialization wouldn't need -u, so we're left with the uncommon case of the uncommon case.
I'd really love to know if Wims would even ever need to use this behaviour himself (and how he would), as well as if anybody else would. I think showing that there is an actual user-base out there that wants a feature because
they plan to use it, not just because they think it is a "nice idea", is the real test of utility. I'm not seeing this either. That's why I asked what is wrong with /set.
I'm of the pragmatic opinion that we should be adding things with
real need rather than "just cause it's a small change and we can". The latter has no limit to what can be added, and creates a messy language-- mIRC is messy enough, but that shouldn't be an excuse to make it worse. This is of course my opinion only, but I'm just expressing my opinion on the feature, you can feel free to ignore my opinion if you like. You know, "if you have nothing useful to say", and all.
