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

Too restrictive return type in std.math.min #3035

Closed
Ekdohibs opened this issue Aug 9, 2019 · 1 comment
Closed

Too restrictive return type in std.math.min #3035

Ekdohibs opened this issue Aug 9, 2019 · 1 comment
Labels
bug Observed behavior contradicts documented or intended behavior standard library This issue involves writing Zig code for the standard library.
Milestone

Comments

@Ekdohibs
Copy link
Contributor

Ekdohibs commented Aug 9, 2019

Since 2cd5e55, the return type of std.math.min is made more restrictive in some situations. However, it seems to me that it is made too restrictive: if A and B are both signed ints (for instance, i16 and i32), then the most restrictive type able to contain the result is the widest of the two. Indeed, in the above case, the minimum might be as little as -2^31, which does not fit in an i16.
Likewise, floats are always signed and the return type should be the widest of the two.
I am not sure about comptime ints and floats: should the return type depend on the comptime value?

@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior standard library This issue involves writing Zig code for the standard library. labels Aug 9, 2019
@andrewrk andrewrk added this to the 0.5.0 milestone Aug 9, 2019
@andrewrk
Copy link
Member

andrewrk commented Aug 9, 2019

Thanks for the report. This is a good argument in favor of inferred return types (#447).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

No branches or pull requests

2 participants