[#70977] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3 — arai@...
Issue #11473 has been updated by Shunichi Arai.
3 messages
2015/10/04
[#70982] limiting scope of magic comments like frozen_string_literal — Eric Wong <normalperson@...>
How about being able to limit the scope of magic comments like
4 messages
2015/10/05
[#71062] [Ruby trunk - Bug #10892] Deadlock in autoload — eregontp@...
Issue #10892 has been updated by Benoit Daloze.
4 messages
2015/10/12
[#71090] Re: [Ruby trunk - Bug #10892] Deadlock in autoload
— Eric Wong <normalperson@...>
2015/10/14
eregontp@gmail.com wrote:
[#71127] [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call — normalperson@...
Issue #11607 has been updated by Eric Wong.
3 messages
2015/10/20
[#71164] [Ruby trunk - Feature #11614] [Open] [RFC] use id_table for constant tables — normalperson@...
Issue #11614 has been reported by Eric Wong.
3 messages
2015/10/22
[#71211] [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call — naruse@...
Issue #11607 has been updated by Yui NARUSE.
6 messages
2015/10/27
[#71212] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Eric Wong <normalperson@...>
2015/10/27
Yes, user must check if the function is MT-safe. Probably fine
[#71246] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Aaron Patterson <tenderlove@...>
2015/10/28
On Tue, Oct 27, 2015 at 08:54:07AM +0000, Eric Wong wrote:
[#71254] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Eric Wong <normalperson@...>
2015/10/28
Aaron Patterson <tenderlove@ruby-lang.org> wrote:
[#71230] [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations — tenderlove@...
Issue #11625 has been updated by Aaron Patterson.
5 messages
2015/10/27
[#71236] Re: [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations
— Юрий Соколов <funny.falcon@...>
2015/10/28
What's about other hashsum algos? MD5, SHA2, etc
[#71242] Re: [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations
— Eric Wong <normalperson@...>
2015/10/28
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#71239] [Ruby trunk - Bug #11384] multi-threaded autoload sometimes fails — shugo@...
Issue #11384 has been updated by Shugo Maeda.
4 messages
2015/10/28
[ruby-core:71166] Re: [Ruby trunk - Feature #11537] Introduce "Safe navigation operator"
From:
Matthew Kerwin <matthew@...>
Date:
2015-10-22 21:19:47 UTC
List:
ruby-core #71166
On 23/10/2015 2:46 AM, <merch-redmine@jeremyevans.net> wrote: > > Issue #11537 has been updated by Jeremy Evans. > > > Tom Reznick wrote: > > Hi, > > > > I think we may have found some unexpected behavior with the `.?` operator. > > > > If I call the following: > > > > s = Struct.new(:x) > > o = s.new() > > o.x #=> nil > > o.x.nil? #=> true > > o.x.?nil? #=> nil > > o.x.kind_of?(NilClass) #=> true > > o.x.?kind_of?(NilClass) #=> nil > > o.x.methods.include?(:nil?) #=> true > > > > > > While it's arguably a bit peculiar to try to check that `nil` is `nil`, in a `nil`-safe way, `.?kind_of?(NilClass)` could reasonably return `true`. > > I think it's completely expected that `nil.?kind_of?(NilClass)` returns `nil` and not `true`. The whole point of `.?` is to return `nil` without calling the method if the receiver is `nil`. I'm not sure if `.?` is a good idea syntax-wise, but if you are going to have it, it shouldn't have special cases for specific methods. > I agree, or put another way: if you're testing for nil in two ways, .? has higher priority. That makes it a programmer issue, not a ruby one.