Discuss the future of the AutoHotkey language
Posts: 479
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: Nothing.

13 Sep 2018, 21:02

How would you handle division by 0? Currently it returns an empty string, so if implemented it should probably return nothing. I very much don't want to see an exception/error, much less different classes of errors, such as 1/0 = Infinity or even worse, 0/0 = NaN.

I just want to say I enjoy the simplicity of the current language, but would also like the benefits of stronger typing, which is necessary in my opinion for AutoHokey to evolve.

Re: Nothing.

13 Sep 2018, 23:25

division wrote:Division by zero causes an exception to be thrown.

Posts: 100
Joined: 21 May 2015, 18:21

Re: Nothing.

30 Sep 2018, 11:15

While I can see the value of this change, I also don't fully understand all of the implications of it, which worries me a bit.

As someone who writes a lot of long and moderately complex AHK programs, and who works with others who are less experienced with the language but also use it a lot, it is extremely rare that I ever have worried about the ambiguity of "" in AHK. Really the only time I recall encountering issues with this is related to object keys, and in those cases it did not take long for me to understand what the limitations were and where I needed to be careful in order to ensure I don't introduce unexpected bugs. It is something that I rarely think about when programming in AHK.

On the other hand, a change like this makes me a bit nervous about whether we are heading to a landscape more similar to javascript, where testing of different "falsey" values is required in common workflows, forcing a larger number of users to worry about the differences between those various falsey values. For example, when I program in javascript, I regularly have to look up the differences between things like "", null, and undefined, and it is difficult for me to remember the difference between testing those values or where I need to worry about them. There are even different operators recommended to test them in different scenarios (== vs ===), etc.

I do see the usefulness of something like an "unset" value in AHK in certain scenarios, but I would advocate that we try and make sure such a change does not introduce unnecessary additional complexity into common workflows that less experienced users will have to deal with. I think there is a cost/benefit analysis that needs to be taken into account here.
Posts: 6680
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Nothing.

30 Sep 2018, 15:57

Thanks for the input, and let me reiterate:
lexikos wrote:No, this is not part of any plan. It is just a bunch of thoughts and hypotheticals that I wrote down in response to someone indirectly requesting null, as I wrote at the top.
No change happening here, just discussion.
User avatar
Posts: 7410
Joined: 29 Sep 2013, 17:08
Facebook: J0EDF
Google: +joedf
GitHub: joedf
Location: Canada

Re: Nothing.

02 Oct 2018, 08:25

This is a non-existent issue... :HeHe:
Image Image Image Image Image
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x8GB G.Skill RipJaws V - DDR4 3280 MHz | [About Me] | [ASPDM - StdLib Distribution]
[Populate the AHK MiniCity!] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library] | [About the AHK Foundation]

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 10 guests