[#79914] [Ruby trunk Bug#13282] opt_str_freeze does not always dedupe — normalperson@...
Issue #13282 has been reported by Eric Wong.
4 messages
2017/03/05
[#80140] [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus) — shyouhei@...
Issue #13295 has been updated by shyouhei (Shyouhei Urabe).
5 messages
2017/03/13
[#80362] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— Eric Wong <normalperson@...>
2017/03/26
shyouhei@ruby-lang.org wrote:
[#80368] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— SASADA Koichi <ko1@...>
2017/03/27
On 2017/03/26 15:16, Eric Wong wrote:
[#80205] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint — Eric Wong <normalperson@...>
duerst@ruby-lang.org wrote:
4 messages
2017/03/17
[#80213] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint
— Martin J. Dürst <duerst@...>
2017/03/17
Hello Eric,
[#80290] [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch — normalperson@...
Issue #13355 has been reported by normalperson (Eric Wong).
4 messages
2017/03/23
[#80410] Re: [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch
— Eric Wong <normalperson@...>
2017/03/27
normalperson@yhbt.net wrote:
[#80415] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
5 messages
2017/03/28
[#80488] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
4 messages
2017/03/29
[ruby-core:80166] [Ruby trunk Misc#13283] Disable `&' interpreted as argument prefix warning when passing symbol to Enumerable#map
From:
simon@...
Date:
2017-03-14 23:55:09 UTC
List:
ruby-core #80166
Issue #13283 has been updated by urbanautomaton (Simon Coffey). mojavelinux (Dan Allen) wrote: > The alternative, a bitwise operation on a symbol, makes little sense. That's especially when the bitwise operator is directly adjacent to the symbol. Bitwise AND isn't the only interpretation of infix binary `&`, though. Just looking in stdlib, `Set#&` means set intersection, and anyone can define `#&` on any class they like to mean whatever makes sense to them - that's the joy of ruby. What appears to be common sense in the example you gave may be completely unclear in another context. Adjacency means different things in other circumstances, too, and infix operation is totally possible with this specific whitespace configuration - the interpretation depends on the operands, and a warning is emitted whether it's interpreted as unary or binary `&`: ~~~ $ irb -w > 1&2 => 0 > 1 &2 # infix binary, warning (irb): warning: `&' after local variable or literal is interpreted as binary operator (irb): warning: even though it seems like argument prefix => 0 > x, y = 1, 2 > x &y (irb): warning: `&' after local variable or literal is interpreted as binary operator (irb): warning: even though it seems like argument prefix => 0 > def a; 1; end > b = 2 > a &b (irb): warning: `&' interpreted as argument prefix TypeError: wrong argument type Fixnum (expected Proc) ~~~ Essentially the warning is to let you know that you're depending on interpreter behaviour that can be very hard to infer by visual inspection (indeed you frequently can't know whether the LHS is a local variable or method until runtime, ironically because of optional parens). It may be just me (and I confess I'm a "use parens all the time" type), but it seems so much simpler to retain the warning and accept that there are some occasions when parens are either necessary or advisable to disambiguate the syntax. You're using them anyway in method chains, you're just putting them around (some) expressions instead of (some) argument lists. ---------------------------------------- Misc #13283: Disable `&' interpreted as argument prefix warning when passing symbol to Enumerable#map https://bugs.ruby-lang.org/issues/13283#change-63605 * Author: mojavelinux (Dan Allen) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- A common idiom in Ruby is to pass a symbol reference to `Enumerable#map`, which in turn invokes the corresponding method on each entry. Case in point: ~~~ %(a b c).map &:upcase ~~~ Yet, when warnings are enabled, this line produces the following warning: ~~~ warning: `&' interpreted as argument prefix ~~~ Perhaps we can all agree that's what this statement *should* do, and in fact Ruby does it. So there's really no reason for this warning. The alternative, a bitwise operation on a symbol, makes little sense. That's especially when the bitwise operator is directly adjacent to the symbol. The workaround to squelch the warning is to add parentheses: ~~~ %(a b c).map(&:upcase) ~~~ However, it's one of the few cases in Ruby where parentheses are mandatory (for an isolated statement). For those of us who prefer to drop parentheses for code style, this is an irritation. It's also one of the most common warnings I've seen Ruby report when warnings are enabled, so it's also just noisy. Can this warning be removed? -- 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>