-
Notifications
You must be signed in to change notification settings - Fork 58
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
Signal(n, reset=x) silently drops any bits in x past the n-th bit #183
Comments
I think a better solution is to warn when the reset value gets truncated. having the max adjusted by the reset value seems like an excellent way to write obfuscated code. |
This interacts badly with a case where the reset value is
Maybe, but the case I had in mind here is things like:
where you really don't want to repeat yourself, but are basically forced to with the current code. |
maybe special case negative numbers on unsigned signals when This would allow in any case, I think it's a bad idea to have |
That would work, yeah.
The reason I don't like the pattern of |
What about something like |
I think we should avoid |
I don't think using strings as sentinel objects is a good way to design an API in general. |
any other non-numeric value would work just as well since
|
An argument shouldn't toggle between being a number (or something castable to number) and another completely arbitrary type. You can, but you shouldn't; this generally means you're trying to overload one argument too much. Yes, the Anyway, I have noted your opposition to the design I proposed. You're not the one who did that so I will look at other options. |
(Was: "Signal(reset=x) should be equivalent to Signal(reset=x, max=x+1)")
Right now the reset value gets silently truncated, which is undesirable.
The text was updated successfully, but these errors were encountered: