Issue #5310 has been updated by Alexey Muranov.


Hello, i also do not understand very well the issue.

Am i right that it has to do with the difference between #to_int and #to_i methods, similar to the difference between #to_ary and #to_a methods?
Do i understand correctly that #to_a is a conversion to an Array of anything that can be converted, and #to_ary is an "easy conversion to Array" reserved for objects that are essentially arrays, and similarly #to_int is reserved for objects that are essentially integers?
In this case i agree with the proposal: to convert a Float to Integer, only #to_i should be allowed, because Floats store approximate values, and Integers store exact values, so Floats are not "essentially" Integers.

I think it would be nice if the rule for using #to_ary and #to_int would be the following: conversion back and forth (if a corresponding inverse conversion exists) should always return the same value.
Also the conversion should when possible commute with some operations: sum, concatenation, etc.
Currently i get: (10000000000000000.to_f+1.to_f).to_int #=> 10000000000000000
(but of course #to_f is not an "easy conversion", so this in not wrong).
Probably this is impossible to observe exactly, but maybe to some extent?
This is just an idea.

Alexey. 
----------------------------------------
Feature #5310: Integral objects
http://redmine.ruby-lang.org/issues/5310

Author: Kenta Murata
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0


I believe it is ambiguous what object can behave as an integral number.
I don't think the current use of Object#to_int isn't appropriate for this purpose.

The most understandable example is Float#to_int.
It should raise error for all float values because they always have uncertainty,
but it doesn't and returns an integral part of it.

I propose to change the use of Object#to_int for the next release of Ruby.
I recommend the following specification changes:

(1) Remove to_int method from Float and BigDecimal.
(2) Rational#to_int returns an Integer only if its denominator is 1. Otherwise, it raises an appropriate error.
(3) Complex#to_int returns the result of to_int of its real part only if its imaginary part is exactly zero (0.0 isn't exactly zero).

If anyone have another idea, please give me your comment.


-- 
http://redmine.ruby-lang.org