-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDScript: Add INFERRED_DECLARATION
warning
#82139
GDScript: Add INFERRED_DECLARATION
warning
#82139
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks @dalexeev !
My only thoughts are that it would be odd if a user enabled INFERRED_DECLARATION
but not UNTYPED_DECLARATION
. You would get a warning if you infer type, but not if the type is undeclared and not inferred. Maybe we could put some kind of example somewhere in the documentation about these two warnings, so users know what to expect?
Great changes though! I approve 👍
Here:
|
It wasn't a strong enough warning in my opinion. I think it might be better to strongly recommend that the warning only be turned on if |
cc33fd1
to
4ce2730
Compare
Changes look good! Thanks again! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved for 4.2 by the GDScript team during our meeting.
Thanks! |
untyped_declaration
warning #81355.Note A. This warning is in addition to
UNTYPED_DECLARATION
, rather than including to. In my opinion, this makes the most sense because if the user enables all warnings, then they won't end up with a situation where one declaration generates both warnings.So the user has a choice:
UNTYPED_DECLARATION
, use static types (explicitly or implicitly), gaining the benefits of static checks.auto
keyword.It's technically possible to only enable
INFERRED_DECLARATION
, but I don't see much point in doing so.Note B. This is a bit against the style we recommend, since a warning is generated on any type inference. It doesn't matter whether the initializer contains a type name or not. The warning requires that you specify the type explicitly:
While this is more verbose and we can implement this check, I don't think we should do it. This verbosity gives additional reliability.
For example, if you have
var x := Type.new()
, you could forget about the type and accidentally change it when you change the value toSubType.new()
. Or copy-pasteVector2i(128, 96)
in place ofVector2(64, 48)
and change the type fromVector2
toVector2i
without noticing it due to implicit conversions.Note С. I'm not sure about the name, maybe
INFERRED_TYPE_DECLARATION
is better (instead ofINFERRED_DECLARATION
)?CC @ryanabx