-
Notifications
You must be signed in to change notification settings - Fork 9
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
Strict mode #143
Comments
Is there some benefit to doing that? When such a parameter has a nullable type, and even when it has a default value, it still works the same as if not passing anything, or not? 🤔 |
Syntactically it works yes. But I already see this becoming a source of problems because the warning about setting the value to null can easily be ignored. Even tho a parameter can be nullable if the input wasn't the output probably shouldn't be. This nullability makes such an issue not easy to find later because the app wouldn't error anywhere since the UI is probably built to handle |
And are you suggesting not to put nulls (when mapping is not found) only to named/optional parameters, where it's okay, or also for positional parameters, where that would be an error? |
I think two levels of strictness might make sense.
|
I think 2 is how it works now -- when fields match, but no maptype/typeconverter is configured, it fails. 1 can be done probably. Would you want to spec that, then confirm the spec with us, and code it? |
I'll have to look for an example but I think it just prints a warning and sets it to |
I want to propose another build option I'd call
strict
mode which disables automatically setting fields to null if there is no mapper function available. The warning can be ignored to easily this option would fail the build if a mapper cannot be found.Sidenote: The implementation should probably find as many errors as possible before failing in the end.
The text was updated successfully, but these errors were encountered: