https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112019-07-05T03:27:56ZRuby Issue Tracking SystemRuby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=791212019-07-05T03:27:56Zsawa (Tsuyoshi Sawada)
<ul><li><strong>Subject</strong> changed from <i>Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthy</i> to <i>Let boolean option (such as `exception` in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational`) be falsy vs. truthy</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/79121/diff?detail_id=52457">diff</a>)</li></ul> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=791242019-07-05T06:02:13Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>I don't have a huge preference either way, but this may be a design decision, so perhaps we<br>
can ask matz either way; also in how strong the concept of "falsy" and "truthy" is in ruby.<br>
I assume there were design considerations for when matz added nil and false and not<br>
considered both to be equivalent (e. g. if some value is nil, you can use that to<br>
distinguish it from true or false).</p>
<p>I think we can find examples where nil being treated as false makes sense, but we may also<br>
consider cases where nil being false does not make a whole lot of sense, e. g. if that<br>
variable would lateron be initialized to become a String or Array. Perhaps that may<br>
have been a reason why you did limit the suggestion to only specific methods, e. g.<br>
chomp in Kernel#gets. For specific methods, it may be that it makes sense to only<br>
distinguish true/false boolean states.</p>
<p>Aside from the conceptual and design consideration, what impact would we be able to<br>
observe if this would be changed? I have not thought through all the given methods<br>
yet. :)</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=791592019-07-06T14:00:46ZEregon (Benoit Daloze)
<ul></ul><p>I agree for methods taking an :exception keyword argument.<br>
I would consider this a bug to treat <code>nil</code> as "want exception".</p>
<p>Do you have examples of other methods taking a boolean option and treating <code>nil</code> the same as <code>true</code>?<br>
Those should probably be fixed too, but they might be hard to find.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=791632019-07-06T16:45:59Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/2963">@sawa (Tsuyoshi Sawada)</a> Could you write a code example in the description? It would be very helpful to make the developer meeting efficiently.</p>
<pre><code>p Integer("z", exception: false) #=> nil
p Integer("z", exception: nil) #=> excepted: nil, actual: invalid value for Integer(): "z" (ArgumentError)
</code></pre> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=792612019-07-10T05:01:35Zsawa (Tsuyoshi Sawada)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/79261/diff?detail_id=52560">diff</a>)</li></ul> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=792622019-07-10T07:41:11Zsawa (Tsuyoshi Sawada)
<ul><li><strong>Subject</strong> changed from <i>Let boolean option (such as `exception` in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational`) be falsy vs. truthy</i> to <i>Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthy</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/79262/diff?detail_id=52562">diff</a>)</li></ul> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=792832019-07-11T07:30:41Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Tracker</strong> changed from <i>Feature</i> to <i>Bug</i></li><li><strong>Backport</strong> set to <i>2.5: UNKNOWN, 2.6: UNKNOWN</i></li></ul><p>It's a bug. It should be fixed.</p>
<p>Matz.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=792862019-07-11T08:50:27Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Note: The rdoc of Kernel#Integer says:</p>
<blockquote>
<p>Passing <code>nil</code> raises a TypeError, while passing a String that<br>
does not conform with numeric representation raises an ArgumentError.</p>
</blockquote>
<p>and states:</p>
<blockquote>
<p>This behavior can be altered by passing <code>exception: false</code>,<br>
in this case a not convertible value will return <code>nil</code>.</p>
</blockquote>
<p>So the current behavior is as documented, at least.</p>
<p>And this seems coming from <code>IO#read_nonblock</code> and so on.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=792872019-07-11T09:17:00Zsawa (Tsuyoshi Sawada)
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>this seems coming from <code>IO#read_nonblock</code> and so on.</p>
</blockquote>
<p>I initially had a feeling that I had seen this opposition between <code>false</code> vs. other values somewhere else, but had forgotten where. Now that nobu has pointed it, I would like to request these related keywords be turned to falsy vs. truthy as well.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=792932019-07-11T11:15:03Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset <a class="changeset" title="Check exception flag as a bool [Bug #15987]" href="https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/3e7d002118a92fad5934e11c75be6768a1476c1b">git|3e7d002118a92fad5934e11c75be6768a1476c1b</a>.</p>
<hr>
<p>Check exception flag as a bool [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` b... (Closed)" href="https://bugs.ruby-lang.org/issues/15987">#15987</a>]</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793042019-07-11T15:52:51Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>It doesn't feel good for me to allow arbitrary values other than <code>true</code> as truthy.<br>
<code>nil</code> as falsy is not so weird...</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793052019-07-11T15:58:57Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Options are:</p>
<ul>
<li>accept normal truthy/falsey value for boolean (using <code>RTEST()</code>)</li>
<li>accept <code>true</code>/<code>false</code> for boolean; exception for everything else</li>
</ul>
<p>And we should keep consistency.</p>
<p>Matz.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793322019-07-12T03:50:17Zznz (Kazuhiro NISHIYAMA)
<ul></ul><p>I think <code>nil</code> means default behavior.</p>
<pre><code>Integer("") # => ArgumentError
Integer("", exception: nil) # => ArgumentError
Integer("", exception: true) # => ArgumentError
Integer("", exception: false) # => nil
</code></pre>
<pre><code>system("") # => nil
system("", exception: nil) # => nil
system("", exception: true) # => Errno::ENOENT
system("", exception: false) # => nil
</code></pre> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793482019-07-12T07:05:02Zsawa (Tsuyoshi Sawada)
<ul></ul><p>znz (Kazuhiro NISHIYAMA) wrote:</p>
<blockquote>
<p>I think <code>nil</code> means default behavior.</p>
</blockquote>
<p>That does not hold even if you just look at the <code>Kernel</code> methods:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="nb">exit</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">true</span><span class="p">)</span>
<span class="no">Kernel</span><span class="o">::</span><span class="nb">exit</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">true</span><span class="p">)</span>
<span class="no">Process</span><span class="o">::</span><span class="nb">exit</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">true</span><span class="p">)</span>
<span class="nb">exit!</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">false</span><span class="p">)</span>
<span class="nb">gets</span><span class="p">(</span><span class="n">sep</span><span class="o">=</span><span class="vg">$/</span> <span class="p">[,</span> <span class="n">getline_args</span><span class="p">])</span>
<span class="nb">rand</span><span class="p">(</span><span class="n">max</span><span class="o">=</span><span class="mi">0</span><span class="p">)</span>
<span class="nb">readline</span><span class="p">(</span><span class="n">sep</span><span class="o">=</span><span class="vg">$/</span><span class="p">)</span>
<span class="nb">readlines</span><span class="p">(</span><span class="n">sep</span><span class="o">=</span><span class="vg">$/</span><span class="p">)</span>
</code></pre>
<p>These methods have default values other than <code>nil</code>.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793552019-07-12T13:31:45ZEregon (Benoit Daloze)
<ul></ul><p>matz (Yukihiro Matsumoto) wrote:</p>
<blockquote>
<p>Options are:</p>
<ul>
<li>accept normal truthy/falsey value for boolean (using <code>RTEST()</code>)</li>
<li>accept <code>true</code>/<code>false</code> for boolean; exception for everything else</li>
</ul>
<p>And we should keep consistency.</p>
</blockquote>
<p>Both sound fine to me.<br>
nobu implemented the second option.</p>
<p>We can try to keep consistency in the future,<br>
but I think we can't easily change existing methods taking a truthy/falsey argument for compatibility.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793652019-07-12T20:35:54Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>sawa (Tsuyoshi Sawada) wrote:</p>
<blockquote>
<p>znz (Kazuhiro NISHIYAMA) wrote:</p>
<blockquote>
<p>I think <code>nil</code> means default behavior.</p>
</blockquote>
<p>That does not hold even if you just look at the <code>Kernel</code> methods:</p>
</blockquote>
<p>As for optional parameters, there are some inconsistencies.</p>
<blockquote>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="nb">exit</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">true</span><span class="p">)</span>
<span class="no">Kernel</span><span class="o">::</span><span class="nb">exit</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">true</span><span class="p">)</span>
<span class="no">Process</span><span class="o">::</span><span class="nb">exit</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">true</span><span class="p">)</span>
<span class="nb">exit!</span><span class="p">(</span><span class="n">status</span><span class="o">=</span><span class="kp">false</span><span class="p">)</span>
<span class="nb">gets</span><span class="p">(</span><span class="n">sep</span><span class="o">=</span><span class="vg">$/</span> <span class="p">[,</span> <span class="n">getline_args</span><span class="p">])</span>
<span class="nb">rand</span><span class="p">(</span><span class="n">max</span><span class="o">=</span><span class="mi">0</span><span class="p">)</span>
<span class="nb">readline</span><span class="p">(</span><span class="n">sep</span><span class="o">=</span><span class="vg">$/</span><span class="p">)</span>
<span class="nb">readlines</span><span class="p">(</span><span class="n">sep</span><span class="o">=</span><span class="vg">$/</span><span class="p">)</span>
</code></pre>
<p>These methods have default values other than <code>nil</code>.</p>
</blockquote>
<p>And other methods fall back <code>nil</code> to the default value, e.g., <code>File.open</code>.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793722019-07-13T03:28:20Zsawa (Tsuyoshi Sawada)
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>As for optional parameters, there are some inconsistencies.<br>
...<br>
And other methods fall back <code>nil</code> to the default value, e.g., <code>File.open</code>.</p>
</blockquote>
<p>I came up with another alternative.</p>
<p>Since this is about suppressing an exception, I think the concept is close to the optional second argument/block of <code>Hash#fetch</code>. One is keyword argument and the other is positional argument, but that does not mean that the values should behave differently. I think we can imitate it.</p>
<p>That is, when the explicit <code>exception</code> option is given, then that value should be returned instead of raising an error when the string cannot be parsed correctly. This would be a breaking change, but I do not think it will break much existing code because most use cases so far probably only use the <code>exception</code> option with the value <code>false</code>, in which case it currently returns <code>nil</code>, and my proposal would change that to return <code>false</code>, but I do not think that is a big deal.</p> Ruby master - Bug #15987: Let `exception` option in `Kernel#Complex`, `Kernel#Float`, `Kernel#Integer`, `Kernel#Rational` be falsy vs. truthyhttps://bugs.ruby-lang.org/issues/15987?journal_id=793742019-07-13T10:18:44ZEregon (Benoit Daloze)
<ul></ul><p>This issue is closed, it's probably best to discuss on a new one for different ideas.</p>
<p>sawa (Tsuyoshi Sawada) wrote:</p>
<blockquote>
<p>but I do not think that is a big deal.</p>
</blockquote>
<p>IMHO it is a big deal, Integer() should return either an <code>Integer</code> or <code>nil</code>, but never <code>false</code> or any other kind of value.<br>
<code>nil</code> means "absence of value", <code>false</code> doesn't have the same meaning.</p>
<p>I believe everyone understands the exception: keyword should be given some kind of boolean value, using the value for anything else than deciding whether to raise exceptions would be very surprising.</p>