-
-
Notifications
You must be signed in to change notification settings - Fork 134
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
Types::Params::*.optional not handling empty string #419
Comments
I can see how this can be confusing but I doubt we can fix it in any way. "Fixing" would be a breaking change first of all. Second, I don't really know how to fix it given how dry-types works internally, I can't see a good option (yet). |
Oh I was aware of this and even had plans to address it before 1.0.0 😭 It somehow got under the radar! Don't you think this could be improved in 2.0.0? |
I don't see a good way. Good in the sense that matches the internals. You can hack it but hacking things often brings more problems than it solves. Types don't "remember their origin", they don't belong to namespaces. If you change this then it has to be stored in the AST. You can probably keep it in |
@flash-gordon right, you've made really good points! I'll give it some more thoughts...at some point...in the future. Maybe something to address in 3.0.0. I'd keep this one open for the time being and just label it as "unconfirmed" with 3.0.0 tentative milestone assigned...unless you're 100% sure it is not worth the effort and we should address it differently (maybe even remove |
To Reproduce
Expected behavior
this behavior is confusing, I assumed that
Types::Params::Date.optional
equivalentTypes::Params::Nil | Types::Params::Date
The text was updated successfully, but these errors were encountered: