Note that I'm not disagreeing with the suggestion, I'm simply offering simple alternatives. I'm of the opinion that we should keep feature bloat as low as possible and not duplicate functionality across different functions unless there is a significant improvement in the API. In this case I don't see a significant improvement.

I think it's useful to point out that you can already do this with /set, just not with multiple vars at once, but the use-case for multiple vars at once is yet to be seen. As I mentioned, you might see the need for this once or twice in a script. But would you really break your scripts back-compat (seeing as this wouldn't work in 7.22 and earlier) just for a completely cosmetic change that occurs once in your entire script?

I also don't buy the argument that we should add this "because /set has it". /set -l can create local vars, so should we be adding multiple assignment to /set, then? Why should /var have the same features as /set if /set doesn't have the same features as /var? It seems to me that the reason different commands have different features is precisely because they are different commands. Yes, you would get multi-assign by adding the functionality of /set to /var, but again, the actual benefit of this is really not obvious (to me, anyway). It's a nice thought that when something is a small change it's easy to just do it in addition to everything else Khaled is doing. But realize that ultimately, Khaled's time is limited, and ultimately, he will be deciding to implement this instead of something else, for the next version. I'd rather see him squash some small but much more important bugs like this, which is likely to take as much time to fix/test.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"