Originally Posted By: Wiz126
Don't compare apples to oranges, they don't behave the same. $N is nothing like $v1/$v2. They don't change values during the comparisons itself, only after, which is exactly what these identifiers should be doing. ((1 == 2) || ($v2 == 2)), we know $v2 is 2 and we also know it won't magically change to something we don't want it to.


How is this an apples to oranges comparison? It's a situation where global state can be modified based on control flow. $v2 will "magically change" through a subsequent if statement the same way $1 will "magically change" through a subsequent tokenization context. The difference is you're not expecting $regsubex to create a new tokenization context-- but such a behaviour is not unique to $regsubex in mIRC; $findfile does the same thing. In short, there is precedent for $N- being wiped inside identifiers for whatever reason. In this case the reason is admittedly less useful to the user, and I certainly see it as a limitation, but I'm not convinced it's a behaviour that needs changing.

I'm dubious about your "convoluted" argument. Sure, there are some isolated situations where a $regsubex becomes more complicated than it could be if $N worked. Arguing about convenience syntax is a slippery slope though, and we could make that argument in many many places. How much easier would it be if we could specify nicknames in ON TEXT event as matchers-- or network names? Certainly easier-- is it worth the trouble? *shrug*.

How often does a situation really arise where you're using 3 or more $N values inside of a regex? Most likely situations like that are complicated enough already and have some kind of local variable setup phase, so throwing in a few new variables isn't a big deal.

Of course this is all as hypothetical as your example. We don't really know how often this bites people. My experience is completely anecdotal and just one small data point, but I can't remember this ever being a problem for me personally. In such a case, I'd opt for caution-- it seems smarter to choose a robust mIRC over the benefit of fixing the syntax in one specific isolated (potentially uncommon) situation.