;AHK v1:
if var is number
if var is %type%
;AHK v2:
if var is "number"
if var is type
;two-way compatible:
;static:
number := "number"
if var is number
;dynamic:
type := "number"
%type% := type
if var is %type%

Why do you post the half stuff from here (https://autohotkey.com/v2/) into here... even if v2 is not finished at all
Next question.. why do you open mutliple threads about v1 to v2 conversion / changes?

Also I dont see a reason why people should care v2 changes, if it's not finshed and there is not a stable build

The current alpha release is usable, but some features, behaviour or syntax may be altered in the next release or future releases.

People asked me for a summary of what would be involved in converting to AHK v2. I wanted one easy-to-find thread. And further to that, this is basically the post I would have wanted when I wanted to know what would be involved in AHK conversion.

There's a difference between understanding what's involved, and writing a script that automates parts of it (most of it) for you. Hence separate threads.

Well it's interesting, there seem to be two distinct camps. Why ARE you using AHK v2 already? Why AREN'T you using AHK v2 already? Perhaps we can find some people of the contrary opinion and get a little argument going. I'm somewhere in the middle.

My opinion is that AHK v2 was complete enough when I started investigating it, to make it worthwhile to begin work on conversion scripts and understanding the changes. Furthermore I was working on AHK v1 function versions of AHK v1 commands, but it appeared wise to modify this slightly to make it AHK v1 function versions of AHK v2 functions.

Fundamentally though, if you know what the changes will be, you can write your AHK v1 scripts in a way that will make them easier to convert later. This is really important, and a big motivation for the guide above.

One thing that I've done which is quite important, is to distinguish between conversion relating to AHK v1 deprecated practices to AHK v1 preferred practices, as opposed to the pure AHK v1 to AHK v2 conversion. Most of the hard-to-convert stuff is actually moving from deprecated AHK v1 practices to newer AHK v1 practices.

It wasn't my intention to produce something 'better' than that webpage.

Is there a way to check when it was updated? Obviously being more up-to-date can be an advantage.

I have various bits of information that aren't there. Also, there is the emphasis on pointing out AHK v1 good/bad practices, and how *that* is actually the harder part of converting. There is a focus on what you need to do to convert, versus what is the nature of AHK v1 versus v2. Sometimes shorter is better, more focused/prioritised, easier to reread, sometimes longer is better, more detail, more complete. It is a great link, I learnt the core, maybe 80% or more, of what I needed to know about conversion from there. And I did mention it in my guide.

Fundamentally though, if you know what the changes will be, you can write your AHK v1 scripts in a way that will make them easier to convert later. This is really important, and a big motivation for the guide above.

I think this point should not be underestimated. The more AHK v1 users are using code that is closer to AHK v2, the easier the jump and the more likely AHK v2 will be mostly embraced, instead of splitting the user base or causing forks. AHK v1 to AHK v2 summaries, checklists, or tips are helpful.

Fundamentally though, if you know what the changes will be, you can write your AHK v1 scripts in a way that will make them easier to convert later. This is really important, and a big motivation for the guide above.

I think this point should not be underestimated. The more AHK v1 users are using code that is closer to AHK v2, the easier the jump and the more likely AHK v2 will be mostly embraced, instead of splitting the user base or causing forks. AHK v1 to AHK v2 summaries, checklists, or tips are helpful.

I think this would be a good reason to start removing deprecated features in v1 gradually so that users will have o use more similar functions/concepts that v2 will use

i think its pointless to try this. nothing about forcing one to dust off their 12yo ahkbasic script just to replace a bunch of <>, ifEquals and SetFormats will even remotely begin approaching familiarizing them with v2 concepts
if u want to make urself familiar with v2, u need to start coding in v2. and for that to happen, one would have to bring v2 to the forefront and cease with the doom and gloom "every update will break yo scripts" rhetoric, thats regularly being touted all over

I think this would be a good reason to start removing deprecated features in v1 gradually so that users will have o use more similar functions/concepts that v2 will use

i disagree, this will break existing v1 scripts on newer v1 versions

I agree with guest3456 on this point. Removing deprecated features will hurt users. In addition, if we are removing deprecated features from AHK v1, then arguably there is no need for AHK v2. Because new AHK v1 versions will not be backwards compatible with older versions.

Furthermore, being so quick to jump to AHK v2, just for the fun of "the new toy" can be devastating to the community. Think of all the libraries, tools, tutorials, examples, and scripts written in AHK v1, that now become "worthless". Who will rewrite all those libraries and scripts from AHK v1 to AHK v2? In most cases, even people that code in AHK v2, will not go back and rewrite their own scripts. The bigger the script, the more work, the less likely to rewrite. The reality check is that most authors won't, so a massive amount of community value becomes lost.

This is why I feel a slow merge (which planned for or not has happened) has the greater benefit. While the versions become closer together, more tools to help conversion, will arguably make the eventual switch more successful. This includes an outright AHK v1 to AHK v2 tool, where if it can't directly convert code, it can suggest changes to make. This can help those that will be rewriting AHK v1 code to AHK v2, and encourage some of the authors who have written popular libraries and scripts.

I think this would be a good reason to start removing deprecated features in v1 gradually so that users will have [to] use more similar functions/concepts that v2 will use

I've said we could add an option in AHK v1 to #Warn, to: warn against using deprecated practices, when more forwards compatible practices are available.

@swagfag: This option would help with the learning/familiarisation process. And make it quicker/easier to update to AHK v2 later on.

Seems like a good idea. If a user turns such on, it will show what lines of code are deprecated. I know the help manual has this, put having such a feature built into the AHK v1 Interpreter seems even better. Possibly, #Warn could also be configured to indicate AHK v1 lines of code that aren't compatible with AHK v2. As what is deprecated and what is compatible, can be different.

Furthermore, being so quick to jump to AHK v2, just for the fun of "the new toy" can be devastating to the community.

if u think thats the purpose of v2, to be ur "new toy", then uve missed the point entirely

Think of all the libraries, tools, tutorials, examples, and scripts written in AHK v1, that now become "worthless".

yeah, software changes and now the 100th incarnation of someone's implementation-detail-tightly-coupled tooltip library is all broken. boohoo

Who will rewrite all those libraries and scripts from AHK v1 to AHK v2?

their authors; whoever needs the lib; whoever is bored enough to do so; nobody. who rewrote all ahkbasic libraries to make them x64 unicode compatible? the same applies here

In most cases, even people that code in AHK v2, will not go back and rewrite their own scripts. The bigger the script, the more work, the less likely to rewrite. The reality check is that most authors won't, so a massive amount of community value becomes lost.

the reality check is that whether lexikos barges into this thread right this very second to announce v2's long anticipated departure from alpha or he does so 10 years from now, nothing will change.
libraries will still have to be ported over, new ones will still have to be written from scratch.
the thing we're discussing here is whether starting such a transition now outweighs the downsides of the API changing yet again midway through.

This is why I feel a slow merge (which planned for or not has happened) has the greater benefit. While the versions become closer together, more tools to help conversion, will arguably make the eventual switch more successful.

what are u talking about? what merge has happened? v2 diverges from v1 vastly and in more subtle ways than merely syntax. which is incidentally why i find this idea of a conversion tool a total pipe dream.

what are u talking about? what merge has happened? v2 diverges from v1 vastly and in more subtle ways than merely syntax. which is incidentally why i find this idea of a conversion tool a total pipe dream.

I meant similar syntax and abilities between AHK v1 and AHK v2, not an actual merging of source code. This is why AHK v1 has the deprecated syntax warnings in the help file. Hopefully such actions are to make it possible to write AHK v1 scripts in a way that makes it easier to convert them in the future or understand the syntax used in AHK v2.

A conversion tool doesn't have to be perfect, just useful. What it can't convert, it can hopefully make suggestions and link to the help file. I don't think most of the community are advanced or professional level programmers, where switching versions or rewriting scripts will be an easy or fast task. Some scripts can have been tweaked over periods of months, even years, before they became "just right" for their purpose. I think it will be a daunting task for such casual programmers with say scripts of more than 5,000 lines of code or multiple scripts with thousands of lines, to have to convert to AHK v2. This arguably includes some advanced programmers and authors of highly popular tools like AHK Studio, AutoGUI, etc... I think many won't do the conversion, and continue to use AHK v1. Therefore it will probably be best to provide some type of useful incentive or encouragement, which I think a conversion tool is.

Also the circumstances around AHK Basic to AHK v1, is much more different than AHK v1 to AHK v2. According to the public history about AHK Basic, Chris stopped developing completely (kind of retired), so the fork AHK_L (AHK v1) became the official version, as it was continually developed. But debatably that was aided by the web site fracas caused by Polyethene (Titan). Chris appeared to initially hand over the keys (AutoHotkey leadership) to Polyethene, who was developing IronAHK and was trying to reinitiate development of AHK Basic. Possibly IronAHK could have became the official version, or development of AHK Basic restarted. But after the web site "war", Polyethene was kind of voted out, and IronAHK went into hibernation. I mention this, because things could of have gone differently than they are now.

There is nothing stopping a fork of AHK v1, to maintain a backwards compatible version that's continually developed, to oppose AHK v2. Arguably, a lot of users would support that. This is why I think it's better not to provoke a split in the user base, and help make a transition between AHK v1 to AHK v2 be done as smoothly as possible.

When you have 5000 lines of code you are most likely coding inefficient. While I think that conversion tools will be great for new and less advanced users.
Advanced users may or may not use that tool depending on its quality and completeness. Sadly I havent seen any candidates that come close to the quality that I feel is necessary to make me use it.

Regardless I actually think that the removal of old outdated and often poorly written libraries is one of the advantages of moving to AHK v2.
I still hope that AHK v2 introduces a library manager with sufficient quality standards to make creating libraries really worthwhile again.

Many of the new concepts that were introduced with AHK v2 would mean the entire restructurization of the library in question. At that point a rewrite is usually easier.

V2 is like a fresh start for AutoHotkey I'd hate to make do with libraries that were bodged together out of masses of poor practice and were then poorly translated to AHK v2.

When you have 5000 lines of code you are most likely coding inefficient.

I think that's an unfair statement. The size of a program can be reflective of the tasks it must handle, therefore it can become large. For Example, the very popular community tool AHK Studio has over 13,000 lines of code. And I would wager that Maestrith is a better programmer than most.

nnnik wrote:
While I think that conversion tools will be great for new and less advanced users.
Advanced users may or may not use that tool depending on its quality and completeness. Sadly I havent seen any candidates that come close to the quality that I feel is necessary to make me use it.

I can understand your opinion about that, but if somebody wants to give writing a conversion tool a try, I think we can at least be encouraging to them. And over time, it might turn out to be very useful or even a great tool.

nnnik wrote:
Regardless I actually think that the removal of old outdated and often poorly written libraries is one of the advantages of moving to AHK v2.
I still hope that AHK v2 introduces a library manager with sufficient quality standards to make creating libraries really worthwhile again.

Many of the new concepts that were introduced with AHK v2 would mean the entire restructurization of the library in question. At that point a rewrite is usually easier.

V2 is like a fresh start for AutoHotkey I'd hate to make do with libraries that were bodged together out of masses of poor practice and were then poorly translated to AHK v2.

A library manager does look like a good idea. However, the quality of how well written libraries and tools are can be very subjective. A fresh start does not mean that older useful libraries will be rewritten and it's still likely that many valuable resources, tutorials, and tools will be lost and never see a v2 equivalent. Tools or libraries that might not be important to you, might be to other users.

Maybe my previous comments about IronAHK might have ruffled some feathers on another thread, but when I think "fresh start", I visualize something more radical. A version of AutoHotkey that runs on Macs, Androids, and Linux would be refreshingly wonderful. In the case of AHK v1 versus AHK v2, I don't know to what extent "average Joe" will appreciate the differences. And if certain people want to promote how great the differences are between v1 and v2, I would think that conversion tips and conversion tools would be a good place to start.