Forums Bug Reports %var.bf bug or limitation

I'm unsure whether this can be considered a bug or is an intentional limitation, but variables whose names use the .bf suffix to enable big float calculability will fail to do so if the variable name contains another . anywhere else in the name:Prints:
Just in case this is an intentional limitation, I hope it can be changed so that it doesn't become a potential source of frustration for people attempting to quickly enable this feature in existing scripts whose variable names already use a "dot-delimited-parts" convention.


(Tested on a clean installation of the beta version v7.71.1275.)

Thanks this has been fixed in the next beta. Note that as % is a valid variable name all by itself, %.bf is a valid variable name as well.

Interesting... This fact feels vaguely familiar to me somehow, as though I might've known that at one point in time, but I'm not sure I would've remembered or thought of it had you not mentioned it. 🤔

Was this purposely built in or simply a side effect of the way you implemented variables into the language? In any case, I'm noticing that variables named % seem to have a few unique quirks to them - namely, that:

1. A script can have multiple independent local variables with that name:
   Code

   //var -s % 0123 , % 4567 , % 89AB , % CDEF | echo -ga $var( % , 0 )

   Code

   * Set % to 0123
   -
   * Set % to 4567
   -
   * Set % to 89AB
   -
   * Set % to CDEF
   -
   4

2. The = assignment operator cannot be used to assign values to nor create them:
   Code

   alias nullvar_test { 
     % = hello
   }

   Code

   /nullvar_test

   Code

   * /%: not connected to server (...)
   -

3. The optional = of the /var command will be treated as part of the value rather than as part of the command's syntax; mathematical expressions will, of course, not be calculated in such cases:
   Code

   //var -s % 2 ^ 3 , % = 2 ^ 3

   Code

   * Set % to 8
   -
   * Set % to = 2 ^ 3
   -

4. Retrieving values stored in them requires explicit use of $var( % , N ).value: (Presumably to avoid conflict with the modulus operator in certain contexts?)
   Code

   //var -s % hello | echo -ga % | echo -ga $var( % , 1 ).value

   Code

   * Set % to hello
   -
   %
   hello

5. Commands like /inc, /dec, and /unset will only modify a global version:
   Code

   //var -s % 5 | dec -s % | set -s % 99 | inc -s % | unset -s % | echo -ga $var( % , 1 ).value

   Code

   * Set % to 5
   -
   * Dec % to -1
   -
   * Set % to 99
   -
   * Inc % to 100
   -
   * Unset %
   -
   5

Whether or not any of these are bugs and warrant their own reports, I'm not sure... but, I figured it'd at least be worth mentioning them here so that anyone who happens upon this post and wants to try using null-named variables will be aware of their pitfalls and limitations.

(Tested on both v7.71 and beta v7.71.1275.)

Hey lire, have a look at the reply in
https://forums.mirc.com/ubbthreads.php/topics/266011/binvar-named

I only mentioned the part about % where you couldn't echo it. But the same kind of thing was happening where it formerly didn't work to use:

//bset -t & 1 abc | echo -a $bvar(&,1-)

There are no plans to change any of these behaviours. There is far too much history and backward compatibility to consider here. The only reason % by itself was allowed to work in some contexts is either through complete chance or because some scripters requested it. I will not be making any other changes to support it in other contexts.