Molti sono a conoscenza di _
’s special meaning in IRB as a holder for last return value, ma quello è non quello che sto chiedendo qui.Dove e come viene specificata la variabile _ (trattino basso)?
Invece, sto chiedendo di _
quando viene usato come nome di variabile in plain-old-Ruby-code. Qui sembra avere un comportamento speciale, simile a una variabile "non importa" (à la Prolog). Ecco alcuni esempi utili che illustrano il comportamento unico:
lambda { |x, x| 42 } # SyntaxError: duplicated argument name
lambda { |_, _| 42 }.call(4, 2) # => 42
lambda { |_, _| 42 }.call(_, _) # NameError: undefined local variable or method `_'
lambda { |_| _ + 1 }.call(42) # => 43
lambda { |_, _| _ }.call(4, 2) # 1.8.7: => 2
# 1.9.3: => 4
_ = 42
_ * 100 # => 4200
_, _ = 4, 2; _ # => 2
Questi erano tutti fuga rubino direttamente (con puts
s aggiunti) -non IRB-per evitare conflitti con la sua funzionalità aggiuntive.
Questo è tutto un risultato della mia stessa sperimentazione però, poiché non riesco a trovare alcuna documentazione su questo comportamento da nessuna parte (ovviamente non è la cosa più facile da cercare). In fin dei conti, sono curioso di sapere come tutto funzioni internamente, così posso capire meglio cosa è speciale su _
. Quindi sto chiedendo riferimenti alla documentazione e, preferibilmente, al codice sorgente di Ruby (e forse allo RubySpec) che rivela come _
si comporta in Ruby.
Nota: la maggior parte di questo nata da this discussion con @Niklas B.
Mi chiedo se la differenza di comportamento di 'lambda {| _, _ | _} .call (4, 2) 'tra 1.8 e 1.9 è solo un effetto collaterale involontario allora? Come in circostanze "normali" in cui il nome della variabile non può essere duplicato, l'ordine in cui vengono assegnati è irrilevante. –
Wow, mi hai battuto. +1 –
@AndrewMarshall: Sì, penso che il problema "4 vs 2" sia solo un artefatto di come 1.8 e 1.9 gestiscono lo stack. L'unica volta che sarebbe visibile è '| _, _, ... |' perché l'errore di duplicazione è stato soppresso. –