Date: 2019/01/10 (Thu)
Time: 13:00-17:00 (JST)
Place: Cookpad Inc. (Tokyo, Japan)
https://bugs.ruby-lang.org/issues/15462
Logs
Next dev-meeting
- 2/7 (Thu) 13:00~17:00 @MoneyForward (Minato-ku)
About 2.7 timeframe
Check security tickets (confidencial)
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)
- [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
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
- [Feature #15374] Proposal: Enable refinements to #method_missing
- [Bug #15416] 配列リテラル内の引数を伴う括弧なしのメソッド呼び出しで syntax error
- 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: