
info: Avoid annotating types on function expression parameters. (avoid_types_on_closure_parameters at [fhir_designer] lib/app_code_generator/form_service_generator.dart:9)
When I remove Form I get
error: Missing parameter type for 'key'. (strong_mode_implicit_dynamic_parameter at [fhir_designer] lib/app_code_generator/form_service_generator.dart:9)
There is also no quick-fix to suppress the error.
analyzer:
# enable_new_analysis_driver: true
strong-mode:
implicit-casts: false
implicit-dynamic: false
linter:
rules:
# Error Rules
- avoid_empty_else
- avoid_slow_async_io
- cancel_subscriptions
- close_sinks
- comment_references
- control_flow_in_finally
- empty_statements
- hash_and_equals
- invariant_booleans
- iterable_contains_unrelated_type
- list_remove_unrelated_type
- literal_only_boolean_expressions
- no_adjacent_strings_in_list
- no_duplicate_case_values
- test_types_in_equals
- throw_in_finally
- unrelated_type_equality_checks
- valid_regexps
# Style Rules
- always_declare_return_types
# - always_specify_types
- annotate_overrides
# - avoid_as
- avoid_function_literals_in_foreach_calls
- avoid_init_to_null
- avoid_return_types_on_setters
- await_only_futures
- camel_case_types
- cascade_invocations
- constant_identifier_names
# - directives_ordering
- empty_catches
- empty_constructor_bodies
- implementation_imports
- library_names
- library_prefixes
- non_constant_identifier_names
# - omit_local_variable_types
- one_member_abstracts
- only_throw_errors
- overridden_fields
- package_api_docs
- package_prefixed_library_names
- prefer_adjacent_string_concatenation
- prefer_collection_literals
- prefer_const_constructors
- prefer_contains
- prefer_expression_function_bodies
- prefer_function_declarations_over_variables
- prefer_initializing_formals
- prefer_interpolation_to_compose_strings
- prefer_is_empty
- prefer_is_not_empty
- parameter_assignments
- prefer_final_fields
- prefer_final_locals
# - public_member_api_docs
- recursive_getters
- slash_for_doc_comments
- sort_constructor_first
- sort_unnamed_constructors_first
- super_goes_last
# - type_annotate_public_apis
- type_init_formals
- unawaited_futures
- unnecessary_brace_in_string_interps
- unnecessary_getters_setters
- unnecessary_lambdas
- unnecessary_null_aware_assignments
- unnecessary_null_in_if_null_operators
# Pub Rules
- package_names
Dart VM version: 1.24.0-dev.6.8 (Mon Jun 5 15:26:29 2017) on "macos_x64"
Hmmmm. This looks like yet another place where we need to (re)consider strong mode implications.
@bwilkerson: thoughts?
Yes, I agree, the rule should be strong-mode aware.
Not sure this fits here



this works
final response = await childRef.set(_serializeCategory(category)) as Object;
the called set():
Future set(value) => handleThenable(jsObject.set(jsify(value)));
I have been seeing this and definitely is annoying, will look at it in my next batch of fixes.
One more example of this conflict:
// ignore: avoid_types_on_closure_parameters
final iterable = (int length, int value) sync* {
var index = 0;
while (index < length) {
yield value;
}
}(100, 1);
Here, types on closure need to be defined for inference to work.
It also happens in
child: TypeAheadFormField<String>(
textFieldConfiguration: TextFieldConfiguration<dynamic>(
onSubmitted: (dynamic _) {
...
},
),
...
With avoid_annotating_with_dynamic vs strong_mode_implicit_dynamic_parameter.
I guess I'll disable the former.
@pq bumping this issue since this seems like something that should be fixed considering we've had strong mode for over a year now.
The error code strong_mode_implicit_dynamic_parameter was removed in https://dart-review.googlesource.com/c/sdk/+/128821. That probably resolves this issue.
Closing in anticipation of https://dart-review.googlesource.com/c/sdk/+/128821.
Most helpful comment
I have been seeing this and definitely is annoying, will look at it in my next batch of fixes.