Skip to content
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

Cannot use argument name "state" in generated family provider #3731

Open
karelklic opened this issue Sep 7, 2024 · 3 comments
Open

Cannot use argument name "state" in generated family provider #3731

karelklic opened this issue Sep 7, 2024 · 3 comments
Assignees
Labels
bug Something isn't working needs triage

Comments

@karelklic
Copy link

Describe the bug
Using a parameter named state in generated family provider results in a compilation error.

To Reproduce

import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'test_provider.g.dart';

enum SomeState { a, b }

@Riverpod(keepAlive: true)
bool wannaUseState(WannaUseStateRef ref, SomeState state) {
  return true;
}

Results in:

./test_provider.g.dart:147:17: Error: The type 'SomeState' of the getter 'WannaUseStateRef.state' is not a subtype of the type 'bool' of the inherited setter 'ProviderRef.state'.
 - 'SomeState' is from 'package:test/test_provider.dart' ('.test_provider.dart').
  SomeState get state;
                ^^^^^

Expected behavior
state is quite a common name so it should be allowed as parameter name.
The current workaround is to rename the variable to state_.

@karelklic karelklic added bug Something isn't working needs triage labels Sep 7, 2024
@rrousselGit
Copy link
Owner

rrousselGit commented Sep 7, 2024

There's a bunch of reserved keywords. In this case, state clashes with ref.state and Notifier.state

@karelklic
Copy link
Author

Thank you for the info.

Would you happen to know what are the other reserved keywords?

Maybe it's reasonable to briefly mention them in the Parameter restrictions section? (Sadly, I do not understand the riverpod code enough to list them all.)

An alternative solution could be to warn or fail during the code generation phase when a reserved keyword is used.

@rrousselGit
Copy link
Owner

It depends on the version. It's not fixed

But I planed on better handling this once we have macros.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage
Projects
None yet
Development

No branches or pull requests

2 participants