#2727 closed Feature Request (Wont Fix)
optional Datatypes
| Reported by: | anonymous | Owned by: | |
|---|---|---|---|
| Milestone: | Component: | AutoIt | |
| Version: | Severity: | None | |
| Keywords: | Cc: |
Description
The fact that I could not even find one ticket about this probably tells me that I shouldn't ask, but anyway, here we go.
If I remember it correctly then the variant datatype works by converting the content of the variables you are currently working with to the type that makes the most sense. If this is correct than it obviously has to be done every time the user works with a variable and therefore I guess that it slows AutoIt down a lot.
What I am asking for is not to force every user to specify the type of every variable, because this would break every AutoIt v3 script that is still working and it would be completely unnecessary.
What I am asking for instead is a static type system that is completely optional, that works by adding new Keywords and that simply bypasses all the checks and conversions that are currently done.
Example:
Local $a, $b, $c ; no datatype specified -> Variant Local Int $i Local String $s Local Bool $f = ($a > $b)
Thanks for reading.
Attachments (0)
Change History (3)
comment:1 in reply to: ↑ description Changed 11 years ago by anonymous2
comment:2 Changed 11 years ago by Mat
- Resolution set to Wont Fix
- Status changed from new to closed
You are correct that dynamic typing does incur a runtime overhead.
However, you are wrong that this would be "static" typing, and that they would perform any better. You'd still need to (at runtime) check the type of the variable and then do something different depending on the type. The only difference between that and a variant is that the explicitly typed case would result in errors, rather than casting.
I really like explicit typing. I am very fussy in compiled languages about type, you wouldn't even see me writing float f = 4.0; in C++. But there really isn't any point in it, or need for it, in an interpreted langauge like AutoIt.
I hope this explains why I'm closing this. If you still have any questions then feel free to PM me on the forums.
comment:3 Changed 11 years ago by anonymous
Just to clarify (I am not on the forums):
By "static" typing I meant that the type of every variable is known when the script is compiled/run and that errors are thrown when types don't match. This should then allow us to completely skip every check because it can be assumed that every variable already has the correct type, since the script wouldn't be running if that was not the case.
But yes, I do understand why you are closing this.
Guidelines for posting comments:
- You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
- In-depth discussions should take place on the forum.
For more information see the full version of the ticket guidelines here.
Replying to anonymous:
That wouldn't be a problem if the generated representation would be optimized. (I'm sure it isn't.)
(The type system is neither static nor dynamic, it's called (optional) static typing.)
That probably wouldn't help. Quite the contrary, the interpreter would need to check the types at every assignment.
Nevertheless I hope that one day static typing will be part of this language.
A trailing "as" type qualifier works better with functions. That also requires only one new keyword.
Example: func toString ($arg1 as int32) as string
If I remember correctly, there is a project that tries to add this kind of static typing to the language, translating it into normal AutoIt. That reminds me of TypeScript...