- @Flipeador: a = b, a < b, a > b, etc, these are also ambiguous re. objects, no?
- @iseahound: Cool.
- @nnnik: Why would you think that <> had been marked as deprecated? No operator has ever been marked as deprecated.
- @nnnik: How is <> a poor design choice?

- I would keep <> for these reasons:
- I haven't heard one good reason to remove <>.
- Ease of conversion between programming languages and other languages (e.g. SQL and Excel which use <>) is a key strength of AutoHotkey, which supports many syntax features. (It's a strength of AutoHotkey that I am proud of, and something that other languages should aspire to.)
- All operators containing < or > i.e. < <= > >= <> are consistent, case sensitive or case insensitive depending on A_StringCaseSense.
- Having <>, a version of != that was based on A_StringCaseSense, is useful, e.g. !(a <> b) and (a <> b). Otherwise you have to double up on code in certain situations. AHK v2 currently lacks an equality operator that is based on A_StringCaseSense. As an alternative, I have suggested StrOp(a, "=", b) and StrOp(a, "==", b).
- You save thousands of users pointless script conversions/alterations.
- <> has the advantage of remaining constant between AHK v1 and AHK v2, != does not.
- (If AHK didn't have <>, I'd be tempted to suggest it, for greater ease of conversion between programming languages.)

- At the time that you wrote your original post, that wasn't true. (No operator had been marked as deprecated. It's not a big point, I was just surprised by your original post.)
- Btw why would you say that <> is a poor design choice? Plenty of languages/programs use it e.g. Excel and SQL.

So, are you saying that we should have more than one operator that does exactly the same thing just because there are users that come from other languages?. Is it a lot of "mental work" to understand that there is a small difference in the operators between different languages?. You can not please everyone, it's more important to maintain good performance and robust syntax.

a = b, a < b, a > b, etc, these are also ambiguous re. objects, no?

I do not understand what you mean.

a key strength of AutoHotkey, which supports many syntax features

IMO, it is the opposite.

I have suggested StrOp(a, "=", b) and StrOp(a, "==", b)

That's disgusting.

<> has the advantage of remaining constant between AHK v1 and AHK v2

I don't care about this.

Wind♥ws1♂Pro 64-Bits░I make scripts forAHKv2(my v2 compiler) & WIN_7+░SpanishArgentina☺(If any of my code written for v2 has stopped working, send me a private message. I appreciate that you correct my English.)

- Virtually all languages have a Mod operator and a Pow function. AutoHotkey has it the other way round (a Mod function and a Pow operator). I waste endless hours on this when converting between programming languages. (If available I would rewrite all of my library functions, but not my scripts, accordingly.)
- The 'inconvenience' of learning a new symbol is not my point.

- You said that 'obj1 <> obj2' might be ambiguous.
- But so would 'obj1 != obj2'.
- Actually, you made a good point here, '!=' can be more intuitive than '<>' in some cases.
- (FWIW arguably '!=' is unintuitive because it look likes 'not assign', and '!==' would make more sense.)

- For example C++/Java/Python each have a few major basic syntax omissions that AutoHotkey doesn't have. E.g. Python lacks a ternary operator. E.g. in some languages you can't or can't easily use ByRef/default/a variable number of parameters.
- (Versus other languages, AutoHotkey has amazingly flexible if statements. And allows double not for example: if !!x.)

- These can be useful in custom match/comparison functions or in scripts generally. Shrinking certain code 5 to 10 times (e.g. 5 operators, 2 variations: Num/Str).
- Or, you could have a function version of each operator. (Although type (number v. string), and case sensitivity would need to be handled somehow.)

- Code that you didn't write but do use might take advantage of the <> consistency.
- Anticipating compatibility quandaries, I'd compare it to the story of The Three Little Pigs. I'd also consider Python 2/3 and Perl 5/6.

Are there really 2 pages discussing <> OMG
Jeeswg your still too new to remember all the bugs people used to generate with the so called "Flexible" syntax. A much stricter syntax is sorely needed. coming from other languages as you say, you should more than appreciate that. Honestly i wish OTB was enforced and if with () Variables always required deref regardless of context used and numerous other syntax tightening features.

- @tank: I have a long memory! Although I'm not sure what you're referring to re. 'flexible syntax'. Can you be more specific? Thanks.
- I'm also a bit unsure on what you mean by OTB enforced and () variables.
- Do you mean one-liners should require curly braces after if/Loop etc? Do you mean any if/Loop line etc should be able to end with '{'?
- I know that sometimes you need (%var%) to double-deref in 'can be an expression' parameters if you mean that.
- Sometimes multiple ways of doing something is fine e.g. for/Loop/while, sometimes it's bad and can lead to bugs, and in those cases I would suggest scrapping things e.g. AHK v1 command-style parameters.

jeeswg wrote:- Virtually all languages have a Mod operator and a Pow function. AutoHotkey has it the other way round (a Mod function and a Pow operator). I waste endless hours on this when converting between programming languages.

"endless hours"? that can only be two things. either 1. hyperbole in order garner support for your point, or 2. extremely poor googling/doc lookup skills. if i'm dabbling in PHP and need to mod something, of course i have no idea how to do it in PHP, so i google "PHP modulo" and it tells me within seconds. certainly not "endless hours"

- @guest3456: Many times on the forum you will see people engage in hyperbole, e.g. the use of the word 'disgusting' earlier. It's not always a bad thing because it can underline an important point.
- Fine if you choose to challenge me, but you never seem to reflect on whether I have a point or not. In fact, I'd go further, I'm quite selective in my 'use' of hyperbole, you should listen very carefully whenever I appear to use it. Has it occurred to you that I make careful considered choices.
- I have done a lot of conversion from and to AutoHotkey. There may be dozens of conversion issues I've encountered. The two that stick in my mind are: ** -> Pow(), and Mod() -> %. You could easily have 5-10 such conversions in a single function.
- Also, avoidable conversion such as this can be a source of bugs.
- Also, it's easy to dismiss a problem, simply because it doesn't affect you. A month or year later you might change your mind when you experience the same problem.

It just doesn't seem like you choose anything carefully.
In fact it seems like you choose similar to the way t-shirt designers choose the texts on their t-shirts.
I mean you always suggest those operators over and over again.
By now you should have somehow seen that they look like functions not like operators and therefore cannot be created like that.
It reduce the reading flow. But if you dont well then I guess there is just no helping you xD

- You made errors re. the word order, word inclusion, capitalisation, and functionality of this basic A_ variable proposal:
A_MajorAHKVersion - AutoHotkey Communityhttps://autohotkey.com/boards/viewtopic ... 13&t=53924
- This is why even if I like one of your ideas, I am worried about how you will try to implement it.
- I am concerned about your design *choices*.
- (In fact many people are bad at this, hence why having at least 3 to 5 people to check over a proposal first before it gets implemented is a good idea.)
- (It seems a bit rushed, it could be more carefully considered, in its own right, and in relation to other variables e.g. A_OSVersion.)
- I have no problems with people suggesting amendments to any of my AHK proposals. Often they will have good ideas. I hope that you will respond likewise.
- I also hope that you will reflect on what people have told you, before submitting GitHub pull requests, and modify them if necessary (e.g. A_AhkVersionMain or A_AhkMainVersion). AutoHotkey code and features should be of a high standard.

- This doesn't make sense. Please explain.

By now you should have somehow seen that they look like functions not like operators and therefore cannot be created like that.
It reduce the reading flow.

- Mod and Pow as both operators and functions, are simply very very common. Even Excel sheets have ^/Power()/Mod() and Excel VBA has a Mod operator.
- AutoHotkey could have **, Pow(), mod and Mod(). Transform already has a Pow subcommand.

JoeWinograd wrote:Thanks, Helgef. Do you know what the thinking was on removing it?

Hello, I didn't mean to ignore your question, I've been afk. There was a few mentions here.

jeeswg wrote:- I would keep <> for these reasons:

Hello jeeswg .

- I haven't heard one good reason to remove <>.

One good reason is because you want it do so something else,

- Having <>, a version of != that was based on A_StringCaseSense, is useful, e.g. !(a <> b) and (a <> b).

When != was changed, <> was changed too, so by removing <> at the same time, opens it up to be used for something else, as you suggested above. I do not like the suggestion though . !(a <> b) and (a <> b), really? I think it should be (a !<> b) and (a <> b) . Regarding ease of conversion, it is probably one of the simplest changes you will ever encounter. And finally, regarding use in other languages, even including v1, I do not see how that is relevant.

- @Helgef: You would use <> for something else? What? <> is commonly used for 'not equal', so I would keep its AHK v1 functionality.
- (I laughed when I first saw !<>, but actually, I kind of like it.)
- (Basically, it's good just to be able to copy a formula/expression from/to another language, and for it to work with little to no conversion. I've suggested a mod operator and a Pow() function in this vein.)
- People converting from AHK v1 to AHK v2, could safely replace != with <>, if we kept <>. I wouldn't add to the conversion burden unnecessarily, I've already rewritten my scripts that used <>, and it was a reasonably time-consuming endeavour. (Don't risk new bugs in old scripts for no gain.)
- Equivalent functionality should have equivalent brevity. AHK v2 has no <> equivalent of equal brevity (re. case sensitivity based on A_StringCaseSense).
- (My earlier post with other points. Any arguments to remove <>? Anyone?)https://autohotkey.com/boards/viewtopic ... 09#p238609

There were already plenty of arguments. You seem to either ignore or not comprehend them. In any case, at this point it is the wrong question, the question now is, what should we use <> for? You made your suggestion, and I'm sure someone will implement your wish for <>, if someone thinks that is a good idea.

- The arguments(/'arguments') have been few and flaky.
- In 38 posts there hasn't been an actual argument (strong or weak) made for removing <>.

- 1 person said it was a poor design choice. An opinion. (Not an argument.)

- 1 person mentioned this sideways point. (But similar issues occur with !=, which cancels it out.)
- For a <> b: a and b may be different, but not obviously orderable.
- However, anything that you do use to determine equality, probably *is* orderable.
- Furthermore, for a != b: that could be interpreted as 'a = a not b' or 'a not assign b'.

- @Helgef: You said:

One good reason ... opens it up to be used for something else

- Your sentence sounds like: <> should be *removed* ... so it can be *added*.

- So zero arguments.

==================================================

- (1 argument that I anticipated but didn't see:)
- The principle that there should only be 1 way of doing something.
- That is not always smart. Look at how many pythonistas want ++ and -- (even though += and -= are available).
Why are there no ++ and --​ operators in Python? - Stack Overflowhttps://stackoverflow.com/questions/365 ... -in-python
- (And if you try to rigidly enforce this principle, you'll soon find that it becomes untenable.)

- (People might subjectively prefer != to <>. But that is not a sufficient argument to remove <>.)