Issue #19919 has been reported by yui-knk (Kaneko Yuichiro).
----------------------------------------
Bug #19919: Variable assignments in condition are warned however class variable assignment and constant declaration are not warned
https://bugs.ruby-lang.org/issues/19919
* Author: yui-knk (Kaneko Yuichiro)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Is it better to warn for class variable assignment and constant declaration in condition?
```ruby
(x, y = 1, 2) ? x : y # test.rb:1: warning: found `= literal' in conditional, should be ==
if a = 1 # test.rb:3: warning: found `= literal' in conditional, should be ==
end
b = 1
1.times do
if b = 2 # test.rb:8: warning: found `= literal' in conditional, should be ==
end
end
if $a = 1 # test.rb:12: warning: found `= literal' in conditional, should be ==
end
if @a = 1 # test.rb:15: warning: found `= literal' in conditional, should be ==
end
class A
if @@a = 1 # no warning
end
end
if B = 1 # no warning
end
```
I use `ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7)`.
--
https://bugs.ruby-lang.org/
Issue #5825 has been updated by matheusrich (Matheus Richard).
Maybe a different proposal, but if the `def initialize(@a, @b)` is ugly, how about a new method similar to `attr_{reader,writter}` like
```rb
class User
init_with :name, :age
# or maybe
attributes :name, :age
end
User.new("Matz", 21)
```
We could even have an option like `keyword_init: true` for keyword args.
On the other hand, a simple alternative is using the new `Data` class, which already provides this nicety:
```rb
User = Data.define(:name, :age)
User.new("matz", 21)
# or
User.new(name: "matz", age: 21)
```
----------------------------------------
Feature #5825: Sweet instance var assignment in the object initializer
https://bugs.ruby-lang.org/issues/5825#change-104875
* Author: goshakkk (Gosha Arinich)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
I'm very excited about this feature in CoffeeScript, and think it might be a nice-to-have thing in Ruby 2.0.
That's how I think it would look like:
~~~ruby
class Me
def initialize(@name, @age, @location); end
end
~~~
So we can declare `@variable`s in the initializer method parameters definition to avoid assigning instance variables from method arguments by hand, like:
~~~ruby
class Me
def initialize(name, age, location)
@name = name
@age = age
@location = location
end
end
~~~
Want to hear what do you guys think, does that feature worth being included in 2.0?
--
https://bugs.ruby-lang.org/
Issue #19883 has been reported by mame (Yusuke Endoh).
----------------------------------------
Misc #19883: DevMeeting-2023-10-12
https://bugs.ruby-lang.org/issues/19883
* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
# The next dev meeting
**Date: 2023/10/12 13:00-17:00** (JST)
Log: *TBD*
- Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker.
- Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly.
- Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue).
- We will write a record of the discussion in the file or to each ticket in English.
- All activities are best-effort (keep in mind that most of us are volunteer developers).
- The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time.
- *DO NOT* discuss then on this ticket, please.
# Call for agenda items
If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format:
```
* [Ticket ref] Ticket title (your name)
* Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.)
```
Example:
```
* [Feature #14609] `Kernel#p` without args shows the receiver (ko1)
* I feel this feature is very useful and some people say :+1: so let discuss this feature.
```
- It is recommended to add a comment by 2023/10/09. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
- The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format.
- Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion.
--
https://bugs.ruby-lang.org/
Issue #16294 has been updated by Eregon (Benoit Daloze).
Looks good, I think we should merge it.
(and this is already the case on TruffleRuby)
----------------------------------------
Feature #16294: Make MatchData frozen and forbid MatchData.allocate
https://bugs.ruby-lang.org/issues/16294#change-104870
* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
----------------------------------------
Currently, `MatchData.allocate` is allowed, but almost every MatchData method called on it `raise TypeError, 'uninitialized Match'`.
I think MatchData should be frozen, none of its internal fields are mutable and I don't see any use case for storing instance variables on it.
Once frozen, we can implement MatchData#dup and #clone as just `return self`, and we don't need to check for the uninitialized case.
And Marshal can have special treatment to create an initialized MatchData directly.
My main motivation is looking at the code in TruffleRuby required to implement `MatchData.allocate` and check if it's initialized in so many places:
https://github.com/oracle/truffleruby/pull/1792/files
Thoughts? Anyone against?
cc @alanwu
--
https://bugs.ruby-lang.org/
Issue #16294 has been updated by nobu (Nobuyoshi Nakada).
I've forgot this for years, and just happened to discover this branch.
https://github.com/ruby/ruby/pull/8624
----------------------------------------
Feature #16294: Make MatchData frozen and forbid MatchData.allocate
https://bugs.ruby-lang.org/issues/16294#change-104868
* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
----------------------------------------
Currently, `MatchData.allocate` is allowed, but almost every MatchData method called on it `raise TypeError, 'uninitialized Match'`.
I think MatchData should be frozen, none of its internal fields are mutable and I don't see any use case for storing instance variables on it.
Once frozen, we can implement MatchData#dup and #clone as just `return self`, and we don't need to check for the uninitialized case.
And Marshal can have special treatment to create an initialized MatchData directly.
My main motivation is looking at the code in TruffleRuby required to implement `MatchData.allocate` and check if it's initialized in so many places:
https://github.com/oracle/truffleruby/pull/1792/files
Thoughts? Anyone against?
cc @alanwu
--
https://bugs.ruby-lang.org/
Issue #19884 has been reported by p8 (Petrik de Heus).
----------------------------------------
Feature #19884: Make Safe Navigation Operator work on classes
https://bugs.ruby-lang.org/issues/19884
* Author: p8 (Petrik de Heus)
* Status: Open
* Priority: Normal
----------------------------------------
If a class might not be defined we need to add a conditional:
```ruby
defined?(ActiveRecord::Base) && ActiveRecord::Base.some_method
```
It would be nice if we could use the Safe Navigation Operator instead.
```ruby
ActiveRecord::Base&.some_method
```
--
https://bugs.ruby-lang.org/
Issue #19880 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #19880: Missing write barrier in iseq instruction list
https://bugs.ruby-lang.org/issues/19880
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: REQUIRED, 3.2: REQUIRED
----------------------------------------
There's a missing write barrier for operands in the iseq instruction list, which can cause crashes. This bug has been fixed in commit [b3b57f7](https://github.com/ruby/ruby/commit/b3b57f70cc1ee6f40ff10b2abaa518….
It can be reproduced when Ruby is compiled with `-DRUBY_DEBUG_ENV=1`. Using the following command:
```
RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0 RUBY_DEBUG=gc_stress ruby -w --disable=gems -Itool/lib -W0 test.rb
```
The following script crashes:
```ruby
require "test/unit"
```
I have backports for Ruby 3.1 and Ruby 3.2 available here:
3.1: https://github.com/ruby/ruby/pull/8430
3.2: https://github.com/ruby/ruby/pull/8431
--
https://bugs.ruby-lang.org/
Issue #13933 has been updated by kyanagi (Kouhei Yanagita).
While this is slightly off-topic, it's relevant to `MINIMUM`, so I'm noting it here.
`0.0..Float::INFINITY` represents the entire range of floating-point numbers that is greater or equal to 0.0.
Therefore, semantically, the range represented by `0.0..Float::INFINITY` should be the same as `0.0..`,
but the following results contradict this:
```
(0.0..Float::INFINITY).cover?(0.0..) # => false
(0.0..).cover?(0.0..Float::INFINITY) # => true
```
To make this work "correctly", we need the information that `Float::INFINITY` is the maximum value.
If there is any handling regarding the minimum value, it might be necessary to have a similar approach for
the maximum value as well.
----------------------------------------
Feature #13933: Add Range#empty?
https://bugs.ruby-lang.org/issues/13933#change-104858
* Author: ted (Ted Johansson)
* Status: Open
* Priority: Normal
----------------------------------------
Range already responds to #size. It would be nice if it also responded to predicate #empty? :-)
--
https://bugs.ruby-lang.org/