From: "phluid61 (Matthew Kerwin)" <matthew@...>
Date: 2013-02-28T06:59:28+09:00
Subject: [ruby-core:53011] [ruby-trunk - Feature #7978] boolean to_i


Issue #7978 has been updated by phluid61 (Matthew Kerwin).


funny_falcon (Yura Sokolov) wrote:
> Well, yes: ruby is not C and false is not 0. But why false could not be
>  converted to 0 by #to_i ?

That seems to imply that the reverse should hold, but (({!!0 => true})).

Similarly, why should true.to_i return 1, and not -1 (as in Visual Basic) or 43 or 0 (which is also a truthy value)?

It makes sense that if such to- (and maybe from-) conversions are required, they should be bundled in a Module that explicitly defines the mappings.
----------------------------------------
Feature #7978: boolean to_i
https://bugs.ruby-lang.org/issues/7978#change-37166

Author: alexeymuranov (Alexey Muranov)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: next minor


=begin
The current behavior is the following:

  > nil.to_i
   => 0 
  > false.to_i
  NoMethodError: undefined method `to_i' for false:FalseClass

  > true.to_i
  NoMethodError: undefined method `to_i' for true:TrueClass

This does not look very consistent to me.  I think it could be useful to define (({false.to_i})) as 0 and (({true.to_i})) as 1.  I think those are fairly common numeric values for False and True.  These values as strings "0" and "1" are also commonly used in HTML forms to represent boolean values.
=end



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