Date: 2019/01/10 (Thu)

Time: 13:00-17:00 (JST)

Place: Cookpad Inc. (Tokyo, Japan)

Logs

Next dev-meeting

2/7 (Thu) 13:00~17:00 @MoneyForward (Minato-ku)

About 2.7 timeframe

trunk is already 2.7.0

Check security tickets (confidencial)

discussed

Carry-over from previous meeting(s)

It seems no carry-over issue was there.

From Attendees

[Feature #6012] Proc#source_location (ko1)

nobu: this breaks compatibility
ko1: how about specifying the new behaviour by some optional parameter?
matz: we don’t have to take care of old behavior in this case
mame: pry is using source_location#last
naruse: pry will be pleasured in this change, I guess :)
ko1: I’m against to break compatibility
usa: if you really concern to keep compatibility, you should propose this feature as new method.
shyouhei: this feature seems not yet mature.

Frozen string literal [Feature #11473]

Matz: give up on Ruby 3.0. Maybe far future.
Matz: Maybe we should provide our coding style to recommend style and obsolete bad style by something like rubocop.

Special variable for block parameter

$_
@1, @2, @3
Ko1: Which `@1` mean `{|x|` or `{|x, |`
Znz: `@0` means `{|x|`
Akr: ary.map { .to_i }
Knu: … as in Lua

Mark for a method which doesn’t receive a proc

matz: I’m planning to introduce a new syntax to specify that the method does not accept any blocks. proposals?
`&nil`
`&!`
`!&`
`&void`
Matz: Ok, `&nil`.
Ko1: Objection. Many pull-reqs “added &nil” will be opened
Ko1: I have been thinking of making Ruby automatically detect if a method actually takes a block even by checking if it uses a block argument or it has a `yield` keyword in it. To achieve this, I want to ban `yield` from within `eval`, and blockless call of proc/lambda/Proc.new etc. I believe that is the way to go. Please warn for “proc” and “Proc.new” without block as obsolete.
Matz: accepted.
Akr: “lambda without block” has been already warned since 2003 (ruby-1.8.0), How about changing it to an exception?
Matz: accepted.

[Bug #15404] Endless range has inconsistent chaining behaviour (mame)

Can we prohibit (1.. ..1) and (1..1)..1 as a SyntaxError?
matz: ok, prohibit
usa: please add test cases into test_syntax.rb

[Feature #14799] Startless range (aycabta)

Matz: try it.

[Bug #15460] Behaviour of String#setbyte changed (shyouhei)

What is the expected / desired way to fix this?

[Bug #7300] Hash#[] の挙動が 1.9.3 と異なっている (mame)

I think we can remove the compatibility layer for 1.9: Hash[[nil]] #=> {}

[Misc #15347] Require C99 (k0kubun)
[Feature #15445] Reject '.123' in Float() method (mrkn)

Matz: I’d like to keep the behavior. Rather, I’d like to allow “123.” too.

[Bug #15500] Behavior of require method in 2.5 is different from 2.4 and 2.6 (mrkn)

usa: It seems bug. let’s ask hsbt-san

[Feature #15477] Proc#arity returns -1 for composed lambda Procs of known arguments

matz: ok

Non-attendees

[Feature #14444] MatchData: alias for #[]

Naruse: `next_page = response.dig('meta', 'pagination', 'next')&.slice(/&page=(\d+)/, 1)` is better

[Feature #14784] Comparable#clamp with a range

usa: the reporter seems have no interest about startless/endless clamp. But we recognize that we can’t approve range as parameter before accepting startless/endless clamp.
akr: we have to consider many corner cases if accepting Range. Request for feedback.

[Feature #14145] Better Method#inspect

usa: a patch is welcome. We might need to discuss the implementation detail, though.
Matz: the proposal is accepted
Naruse: just an idea, ArgumentError which is raised by arity check should also show such signature.

[Bug #15428] Refactor Proc#>> and #<< (it regards the same problem as #15483 above, but approaches it from a different point of view)

Mame: Use a block. You then want syntactic sugar for passing an argument, and then for partial application, blah blah blah.
knu: We should not add fancy new features around procs and symbols if the real problem is that block syntax is not good enough, like `|x|` is always necessary. (See above for the default block parameter syntax)
Matz: raise an error when the argument does not respond to :call

[Misc #15486] Default gems README.md

[Misc #15487] Clarify default gems maintenance policy
[Feature #15373] Proposal: Enable refinements to #method and #instance_method

matz: go ahead

[Feature #15374] Proposal: Enable refinements to #method_missing

matz: wait a month

[Bug #15416] 配列リテラル内の引数を伴う括弧なしのメソッド呼び出しで syntax error

History:

2006: r10235 removes command from aref_args.
2007: r13821 removes warning from call_args.

*: Should we emit a warning against both cases?
knu: There's so much existing code out there written as follows:

expect(command arg).to eq(value)
f.(Math.sqrt 2)
f[Math.sqrt 2]

[Bug #2250] IO::for_fd() objects' finalization dangerously closes underlying fds (eregon)

The current behavior is dangerous and has caused many spurious test/spec failures which are hard to find and debug. I plan to submit a patch, but I'd like opinions regarding compatibility.

[Bug #15488] const_defined?("File::NULL") の挙動

What is the expected behavior?
matz: ok, try to return “true” in this case. if we find something wrong, will give up.

[Feature #15456] Adopt some kind of consistent versioning mechanism

More uniformity within the ecosystem would be nice.
Naruse replied it.

[Feature #11473] Immutable String literal in Ruby 3

Mame: As I recall, matz said that this has been cancelled at the old developers' meeting. I'd like to confirm.

Matz: Rubocop can be used to agitate people to frozen string, but looks premature for Ruby 3. So try it in Ruby 4.
knu: Rails generators could add the magic comment to auto-generated files to promote the style.
Akira Matsuda: Rails itself uses frozen string literal. It seems that frozen-string-literal by default would not be a big problem.

Carry over: