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

make convert(Integer, x::Float) an error for non-integer-valued x #725

Closed
StefanKarpinski opened this issue Apr 16, 2012 · 2 comments
Closed
Assignees
Labels
breaking This change will break code
Milestone

Comments

@StefanKarpinski
Copy link
Member

As a corollary, we can reinstate automatic conversion of fields to constructors after this.

@ghost ghost assigned StefanKarpinski Apr 16, 2012
@JeffBezanson
Copy link
Member

Should float(2^62+1) also give an error?

@StefanKarpinski
Copy link
Member Author

I was kind of thinking that it might. It's sort of a different approach to "down conversion": if you're faced with a conversion to a less capable type that's going to lose significant information, like rounding a non-integral float, throw an exception. The idea would be that convert(Int, x::Float64) throws an error if the float isn't an exact integer-valued float, since this is often used generically under the assumption that the conversion is safe (indexing, field assignment, ccall). If you just want to do rounding conversion, regardless of such subtleties, you do int(x::Float64), which has to be written explicitly, implying that you're fine with whatever losses.

However, this approach would imply that convert(Int8, typemax(Int64)) should throw an error, which tosses a wrench into our whole scheme for just converting down at the end of integer computations. That's not a can of worms I really want to open again :-\

All of this kind of reminds me of the distinction I once wanted to make between convert and coerce: convert is the "gentle" version — if the value doesn't fit, it throws an exception; coerce is the more forceful version. All the conversions we have now are forceful, but it's handy to have gentler versions, which is why we're concerned about things like indexing, field assignment.

JeffBezanson added a commit that referenced this issue May 22, 2012
  checked_fptoui32, checked_fptosi32, checked_fptoui64, checked_fptosi64
adding integer arithmetic intrinsics with overflow checking for #855
  checked_sadd, checked_uadd, checked_ssub, checked_usub, checked_smul, checked_umul
domain error for int^(negative int), closes #745
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code
Projects
None yet
Development

No branches or pull requests

2 participants