https://autohotkey.com/board/topic/9077 ... -constant/
I've gone back into my code libraries to edit a bunch of functions that require default parameter sentries. Probably goes without saying, but I use these sentries where functions need to pass missing parameters on to other functions, or they may need to use empty string or 0 or the like as a legitimate parameter value (and needing something else for the missing value). I generally use an unlikely string value like "[email protected]" or "`vna" or something for my sentry -- since, to my knowledge, AHK can only have default values which are simple string/numeric literals. Sentries or not, though, these are still strings...
You've made such great improvements in the integer/string distinction in v2, and enabled more predictable behaviors in a lot of my code. I've actually gone in and, where it matters, introduced type checking and exceptions, and it's working great, except for one problem... These sentries create a bunch of extra code in the type checking process to specifically look for them as a special case of string. It would be great if I could use as default parameter values a custom "class NA" that is itself just a dummy sentry object, but which is not a string, and which would allow string type checking to fail on its own without special code looking for and excluding those special magic-string sentry values.
Last time we discussed this, with some other examples about constants/defaults required with Excel automation, you very correctly summarized that I was really making two requests:
And you thought I'd made a better case for #2 than for #1. I was just wondering if you've given #2 any more thought? Of the two, that was my higher priority ask, and definitely what I'm looking to do above with the object as a default parameter value.1) Add constants.
2) Allow something other than a simple literal value as a parameter's default value.
Also, with respect to #1, I raise these together again, as after I spent an hour wading through 10K lines of AHK trying to find a rather elusive bug... it boiled down to an issue that is related to both concepts. Some ambiguously ordered assignment/expression code (my fault!) changed one of my default parameter sentry magic-string "constants", and it broke a whole bunch of type-checking downstream.
Even if you didn't fully exploit the performance benefits of adding constants (which we discussed last time around), just having a keyword const that would cause any later reassignment to throw an exception would be very helpful. That said, I know you don't always have time for all the nice-to-haves... Thanks for your consideration though.