Ответ 1
foo&.bar является сокращением для foo && foo.bar, так что бы вы ожидали результата выражения nil && nil.nil??
Безопасный навигатор (&.) Для nil
Как Ruby 2.3 вводит безопасный навигационный оператор (&.), a.k.a одиночный оператор, поведение объекта nil кажется нечетным.
nil.nil? # => true
nil&.nil? # => nil
Является ли это так, чтобы вести себя так? Или какой-то крайный кейс, который ускользнул при добавлении одинокого оператора?
Ответы
Ответ 2
Это потому, что nil&.nil? является сокращением для nil && nil.nil?. Это будет оцениваться как nil && true, что тогда nil.
(nil && x).nil? всегда оценивает true, для любого значения x.
В то время как синтаксис имеет силу, этот конкретный случай имеет некоторый потенциал, чтобы стать "готовым" для разработчика:
(stuff&.things).nil? = > Это создает true, если файл не существует, или stuff.things возвращает nil.
против. в следующем случае:
stuff&.things&.nil? = > Это создает nil в каждом случае, кроме случая, когда stuff.things возвращает что-то, отличное от nil, и в этом случае он возвратит false.
Из-за трудности в нормальной логической логике дифференцирования между false и nil маловероятно, чтобы это имело смысл в нормальной логике.