Just an explanation for how I encountered these, and comments about the deprecation topic.
I'm not intentionally trying to go to extremes to break things. The one-liner of /testcontinue-1 is based on a //command I was doing in the editbox. In the editbox you can use $& to join 2 lines together with the pipe symbol ignored, like ...
//echo -a test $& | message
... but there's no way to 'trick' the editbox into thinking part of your //command is on a 2nd row, and normally there would be no need for it, just as there's no need to use $& there. And my //command eventually ran into an infinite loop that had been caused by the impossibility of a /var command executing twice in a row between its neighbors.
As for the not-needed bracket, that was created from a normal script where I'd used copy/paste to to put the a series of commands inside an if() condition, and at first I thought this issue was because it was inside the if() but it's not, though it did happen here:
alias testbraket2 {
if (1 == 1) {
{ echo -ag text 1 | echo -ag this doesn't halt or show this message | halt }
}
echo -ag text 2 should be halted
}
If this had generated an error, I would've been fine with that and removed the extra curly brackets, as the glitch happens regardless if the end-brace following the 'halt' is on the same line or on the next row. But eventually this ended up being the result of a trouble-shooting to figure out why the script continued to execute even though it had branched to show the echo, and then to determine what's the least edit that would make it behave as expected.
* *
As for Protopia's command about preserving backwards compatibility, a lot of people have different ideas of what should be preserved, and what can be discarded.
https://forums.mirc.com/ubbthreads.php/topics/269731/re-readini-vs-writeini#Post269731The #B in this link was an example of this, where the cause of $readini and /writeini handling "item name" differently is because of supporting the legacy usage of identifiers like $read etc where their parameters are not enclosed inside the parenthesis.
While I personally have never used the no-parenthesis format, I do rarely see scripts still going around which use them. You can often get an idea of how old a script is by how many obsolete commands it uses. Such as a recent script I was helping with where they were using $ifmatch instead of $v1, $hregex instead of $hfind, or trying to use a .dll to add functionality to a script that was added to the language a couple decades ago.
As a possible solution toward deprecating things, there could be a new section in /help where it lists the deprecated commands/identifiers/syntax, and gives examples of usage that's been taken away and what should be done to fix it. It's easiest to do with identifiers, where with $read it could halt the script with an error that displays a message pointing them to /help for the fix, rather than triggering an identifier warning. The no-parenthesis identifier shouldn't be simply removed, because most scriptors don't immediately understand the difference between $identifier and $identifier(), so using a rare identifier like $sha1 without parenthesis showing an error message saying that $sha1 is not an identifier threw me for a loop the 1st time I saw it, but if a script suddenly showed an error saying that $read did not exist, lots of users, especially non-scriptors, would think it meant that $read() was kaput.
So the deprecated section of /help could give simple examples of old-vs-new syntax, like
old: //echo -a $read -ntw *mir* mirc.ini
new: //echo -a $read(mirc.ini,ntw,*mir*)
For some commands it can be appropriate to do like the deprecated /finger does, behaving the same as noop does
//finger $findfile($mircdir,*.ini,1,echo -a $1-)
//noop $findfile($mircdir,*.ini,1,echo -a $1-)
... but the 'deprecated' section of /help could show like
old: /finger nick
new: /ctcp nick finger
Regarding the advanced notification that Protopia mentioned, one way to do that would be to have a future version include a message during the installation that deprecations were being planned, and to invite users (and especially scriptors) to test the beta version to see how their scripts behave without the deprecated command, which gives them a chance to get things tidy for when the next version-number is officially released.
It may not be sufficient to simply make beta versions available on the forum, because there are a lot of users who never run the beta. Possibly the reason is because the forum post for it paints a dire picture as if the beta is bug infested, when that's rarely the case. The last time I remember a beta version becoming unusable was the time several years ago where a common syntax for $regex was broken and Khaled rushed out a new beta the next day, but typically the difference between $beta and regular is restricted to fixing bugs, and any problems that would be encountered are only using new syntax for existing command/identifiers or new ones.
If there is a beta for deprecated things, it could be something releasd shortly after an official new version, and the only change would be the changes due to deprecation.
--
Or, have a temporary checkbox in options within an official release, that is unchecked by default, where checking the box would deprecate things like $readini without the parenthesis. Then, commands/identifiers planned to be deprecated would respond to that checkbox for 1-2 releases before the deprecation becomes permanent even if the box weren't checked, at which point the language could 'move forward' without being inhibited by that aspect of deprecation. The same options box could continue affecting a sliding series of items if there's more than just a single Mass Extinction Event.
If commands or identifiers do start to be deprecated, then scripts could be helped out by an $iscommand() and $isidentifier() to see if something is part of the internal language, and is not the same as $isalias() seeing scripted aliases. For $isidentifier to tell the difference between $readini and $readini(), it could be $isidentifer(readini) vs $isidentifier(readini,1)
--
As for deprecating the scripting syntax in this thread, that might be difficult to attach to a legacy message, and an options checkbox would require having 2 copies of the scripting engine loaded, so would probably be only in the things-to-be-deprecated beta that doesn't support the things in the scripting syntax that is rarely used, and has a simple alternative which would be just as good if not better. Khaled would know better than we do what kind of support for edge cases there is in the parsing engine which would needlessly slow things down for the 99.99%, and which has a better alternative.
