change int(::Float64) to error on non-integral values

[StefanKarpinski]

We've discussed this before and I think it's a good change. This forces people to be explicit about whether they want rounding, truncation, or whatever. The current behavior is a gotcha for people coming from C. Related to which, do we have a document somewhere for people coming from C where we can mention that int/int = float, since that is a surprise when coming from a static language?

[jiahao]

Perhaps the Noteworthy Differences from Other Languages section of the manual?

[StefanKarpinski]

Ah, yes. I was wondering where that section had gone. We should probably have a C section in there.

[JeffBezanson]

See also #5413.
To me the value of int(x) is that it's short and convenient. It's not so bad just to say that it does rounding.

[ivarne]

I also think int(x) is an obvious sign that I really want to get a integer back. We have isinteger(x) if you think a non exact conversion deserves an error.

Wouldn't throwing an exception be a major speed bump for such a simple function?

[StefanKarpinski]

I've encountered numerous people coming from static languages who were very surprised that we (a) don't do integer division and (b) do rounding instead of truncation. My justifications are weak. People do, however, seem to agree that requiring the programmer to be explicit about how they want to convert to integers is ok.

[JeffBezanson]

Making things unsurprising to people used to static languages doesn't seem like the right standard at this point.
Rounding is a better default choice. It hasn't been the default in the past because it's slightly more expensive.

[ivarne]

Integer division is just so annoying in python. I regularly waste 30 minutes before realising that both my variables happened to be integers. I don't have a strong opinion on the rounding vs truncation, but rounding is definitely less surprising.

[lindahua]

We have ifloor, iceil, iround, and itrunc. All of these produce an integer given a floating-point value. I don't think they are more difficult to use than int. We should also encourage people to use these functions instead of int to explicitly express their intentions.

[lindahua]

My feeling is that whenever you have more than one ways to define something and none is "obviously more correct" than others, then we should just don't allow that and tell people to articulate what they want explicitly.

[JeffBezanson]

I think the real goal is to get rid of the int function (and its cohorts). That's something I can support. Then we'd just have Int(x) (which is convert), and iround etc.

[lindahua]

@JeffBezanson I agree with this plan.