[#98098] [Ruby master Feature#16824] Follow RubyGems naming conventions for the stdlib — shannonskipper@...

Issue #16824 has been reported by shan (Shannon Skipper).

14 messages 2020/05/01

[#98147] [Ruby master Feature#16832] Use #name rather than #inspect to build "uninitialized constant" error messages — jean.boussier@...

Issue #16832 has been reported by byroot (Jean Boussier).

20 messages 2020/05/06

[#98174] [Ruby master Bug#16837] Can we make Ruby 3.0 as fast as Ruby 2.7 with the new assertions? — takashikkbn@...

Issue #16837 has been reported by k0kubun (Takashi Kokubun).

10 messages 2020/05/07

[#98241] [Ruby master Bug#16845] Building Ruby with old existing system Ruby results in make error with ./tool/file2lastrev.rb — erik@...

Issue #16845 has been reported by ErikSwan (Erik Swan).

7 messages 2020/05/09

[#98256] [Ruby master Feature#16847] Cache instruction sequences by default — jean.boussier@...

Issue #16847 has been reported by byroot (Jean Boussier).

16 messages 2020/05/11

[#98257] [Ruby master Feature#16848] Allow callables in $LOAD_PATH — jean.boussier@...

Issue #16848 has been reported by byroot (Jean Boussier).

27 messages 2020/05/11

[#98318] [Ruby master Bug#16853] calling bla(hash, **kw) with a string-based hash passes the strings into **kw (worked < 2.7) — sylvain.joyeux@...4x.org

Issue #16853 has been reported by sylvain.joyeux (Sylvain Joyeux).

12 messages 2020/05/13

[#98355] [Ruby master Bug#16889] TracePoint.enable { ... } also activates the TracePoint for other threads, even outside the block — eregontp@...

Issue #16889 has been reported by Eregon (Benoit Daloze).

16 messages 2020/05/14

[#98363] [Ruby master Feature#16891] Restore Positional Argument to Keyword Conversion — merch-redmine@...

Issue #16891 has been reported by jeremyevans0 (Jeremy Evans).

23 messages 2020/05/14

[#98371] [Ruby master Feature#16894] Integer division for Ruby 3 — andrew@...

Issue #16894 has been reported by ankane (Andrew Kane).

18 messages 2020/05/15

[#98391] [Ruby master Bug#16896] MakeMakefile methods should be private — eregontp@...

Issue #16896 has been reported by Eregon (Benoit Daloze).

10 messages 2020/05/15

[#98396] [Ruby master Feature#16897] Can a Ruby 3.0 compatible general purpose memoizer be written in such a way that it matches Ruby 2 performance? — sam.saffron@...

Issue #16897 has been reported by sam.saffron (Sam Saffron).

25 messages 2020/05/16

[#98453] [Ruby master Bug#16904] rubygems: psych: superclass mismatch for class Mark (TypeError) — jaruga@...

Issue #16904 has been reported by jaruga (Jun Aruga).

18 messages 2020/05/20

[#98486] [Ruby master Bug#16908] Strange behaviour of Hash#shift when used with `default_proc`. — samuel@...

Issue #16908 has been reported by ioquatix (Samuel Williams).

14 messages 2020/05/23

[#98569] [Ruby master Bug#16921] s390x: ramdom test failures for timeout or segmentation fault — jaruga@...

Issue #16921 has been reported by jaruga (Jun Aruga).

9 messages 2020/05/29

[#98599] [Ruby master Bug#16926] Kernel#require does not load a feature twice when $LOAD_PATH has been modified spec fails only on 2.7 — eregontp@...

Issue #16926 has been reported by Eregon (Benoit Daloze).

12 messages 2020/05/31

[ruby-core:98401] [Ruby master Feature#16894] Integer division for Ruby 3

From: jzakiya@...
Date: 2020-05-16 06:30:30 UTC
List: ruby-core #98401
Issue #16894 has been updated by jzakiya (Jabari Zakiya).


The following is meant to be an objective assessment of the proposal, taking no stand on approval, or not.

The proposal is for inclusion of the "feature" in **Ruby 3** . By definition, Ruby 3 will be a major version, which will incorporate new features, while trying not to break (too much) prior code. Anyone upgrading will know they will have to modify existing code to use any of the new features. Similarly, any possible breaking changes (e.g. for ``/``, et al) will be psychologically less stressful on the whole, as it will be incorporated into the general upgrade process. I would imagine tools like ``Rubocop`` will evolve to incorporate these changes to assist people to upgrade.

Also, there will undoubtedly be a plethora of blogs, articles, and presentations on all the changes introduced by Ruby 3, so the aware user should not be caught flatfooted on what to look out for in the upgrade process. For a new user it wouldn't matter at all, since whatever the syntax is that's the syntax they would just learn to use (no unlearning needed).

There are two (2) major components to the proposal:
1. should it occur, i.e. is there enough of a rational, et al, basis to make the change.
2. what should be the agreed upon syntax to represent the change.

1) This "feature" is now codified in syntax in various languages, e.g. Python, Crystal, Nim, Sidef, et al (I haven't done an extensive search for a complete list). One explicit purpose (especially for compiled languages like, Nim and Crystal) is to consistently/visually establish the expected result of division.

In a compiled language with explicit types, it's easier for writing the compiler to know if the two arguments are integers then ``//`` tells the compiler to produce another integer, while ``/`` says convert to float. The opposite if the arguments are float.

Also, the source code now becomes visually consistent and explicit for the code writer and its readers.

As a matter of preference, Ruby made the decision to base the result of division using ``/`` on the argument types, so the programmer still had to know the desired outcome and then use the appropriate syntax.

Thus for explicit numbers:   ``9 / 2 = 4``  and ``9 / 2.0 = 4.5``
But also then for variables which could be any type:  ``a.to_i / b.to_i = c`` (integer) and ``a / b.to_f = c`` (float)
Either way, you need to know the proper operational syntax to get the desired outcome.

2) As a matter of operation syntax, it's probably "best" to use familiar syntax for easier/wider adoptability (Crystal, Sidef, and Python use ``//`` while Nim uses ``div``), have it be short, and contexturally non-conflicting. 

I don't know how the usage of ``//`` exists in ``regexs``, but this question's answer is empirical, not subjective. Just do an entire code base check on the symbols ``/`` and ``//`` to produce a baseline profile of their use. I would guess their use is so specific as not to cause contextual parsing problems, especially since Ruby is rife with aliasing of symbols. Also, the use of ``/`` will occur most prominently in numerical heavy modules|code further specifying its use.

I hope this has been helpful.



----------------------------------------
Feature #16894: Integer division for Ruby 3
https://bugs.ruby-lang.org/issues/16894#change-85668

* Author: ankane (Andrew Kane)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
Hi Ruby team,

It'd be great if division in Ruby matched what we all learned in school.

``` ruby
1 / 2 == 0.5
```

New developers wouldn't immediately be confused when they try to do division and experienced developers could stop adding to_f to their code (typically after they get tripped up on the first run). In my experience, floating point division is way more common than floor division. This could definitely break existing code, so I understand it's a decision that shouldn't be made lightly. Overall, Ruby is really intuitive, but this is one place where it's not.

It looks like this was considered for Ruby 2.0 as well as few years ago in #5512, so feel free to close if it's not something you'd like to reconsider right now.

---Files--------------------------------
integer division.png (14.3 KB)


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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread