-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Migrate android_semantics_testing to null safety #111420
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
Conversation
gspencergoog
left a comment
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.
| } | ||
|
|
||
| void _updateRadio(int newValue) { | ||
| void _updateRadio(int? newValue) { |
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.
It seems like this should not be nullable, since is always asserted to be non-null. Either that, or below it shouldn't assert, but rather set to zero or something if the value is null.
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.
The function signature is ValueChange(T?), It can be null if the radioButton is toggle-able. Since the radiobutton is built without toggle-able. I can be sure it won't be null.
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.
No, I don't mean add an assert (I was calling the ! an assertion that it is non-null, which it is, but it's not an "assert", sorry for being confusing).
I'm just saying that if the argument is nullable, and you always force the value to be non-null, then perhaps either the argument should be also non-nullable (which I understand is different than the signature for Radio.onChanged), or the value shouldn't be always forced to non-nullable, and be something like _radio = newValue ?? 0 instead of _radio = newValue!.
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.
It can be nullable for the different use cases of RadioButton, but It can't be null in the RadioButton use case in this file.
If it is null here, that means something is wrong in the code in this file. I think a force cast would be more preferable in this case?
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.
Yeah,OK, I guess since it's a test it's probably fine.
)" This reverts commit e993419.

fixes #90633
4th attempt after a year. Let us pray
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.