New Features in Ruby 2.4

Post by EdHominem » Thu, Jul 21, 2016, 4:27 PM UTC

psyklic wrote: post #10

Rafert wrote: post #4

Earlier quoted context omitted.

It has a historical reason: https://bugs.ruby-lang.org/issues/10617

To summarize* and elaborate: Originally in Ruby, multiple assignment inside a conditional caused a parse error. Why? Because multiple assignment originally always returned an array: irb(main): a, b = nil => [nil] In Ruby, non-empty arrays always evaluate to truthy. (The array above has one element, nil.) Hence, multiple assignment inside a conditional would have been meaningless. For this reason, Ruby threw a parse e…

Post by dlisboa » Thu, Jul 21, 2016, 5:00 PM UTC

elcapitan wrote: post #60

dlisboa wrote: post #57

Earlier quoted context omitted.

Haven't tried it, but the assignment semantics is that the return of the assignment expression is always the right hand side of the operator. They probably kept that semantic. So foo, bar = ['foo', nil] evaluates to ['foo', nil] which is truthy. If the code was: if (foo, bar = [nil, nil]) 'truthy' else 'falsey' end It'd still be truthy even if no variables were "set" (they were actually set, explicitly to nil, but yo…

Interesting. In particular the result with both values being nil is something I would find pretty counter-intuitive.

Post by josho » Thu, Jul 21, 2016, 7:21 PM UTC

toolz wrote: post #47

Why do the old match operators now implicitly set a global variable? I feel like in a year I'm going to be debugging some really weird race conditions because of that change and I can't see any value in it...if I want to use the value of a match operator I'll _always_ save it to a local variable. Can anyone shed any light on this, because my first attempts at grok'ing this change have me really blown away.

Post by jbackus » Thu, Jul 21, 2016, 11:06 PM UTC

psyklic wrote: post #14

jbackus wrote: post #6

Earlier quoted context omitted.

Ah well "You probably shouldn’t do that though" is just my opinion as the author. I didn't play a part in these changes. I just like Ruby enough to dig into their changelog :)

Interestingly, assignment inside conditionals is usually avoided because it is easy to accidentally do an assignment (=) rather than a comparison (==). Note that for multiple assignment this mistake can no longer happen: irb(main): a, b == 3 SyntaxError: syntax error, unexpected ==, expecting '=' Should it still be avoided? :)

    'truthy' if (a, b = [])              # =>
    'truthy' if (a, b = nil)             # =>
    'truthy' if (a, b = [nil])           # =>
    'truthy' if (a, b = [nil, nil])      # =>
    'truthy' if (a, b = [false])         # =>
    'truthy' if (a, b = [false, false])  # =>
    'truthy' if (a, b = [true, false])   # =>
    'truthy' if (a, b = [false, true])   # =>
    'truthy' if (a, b = *[])             # =>
    'truthy' if (a, b = *nil)            # =>
    'truthy' if (a, b = *[nil])          # =>
    'truthy' if (a, b = *[nil, nil])     # =>
    'truthy' if (a, b = *[false])        # =>
    'truthy' if (a, b = *[false, false]) # =>
    'truthy' if (a, b = *[true, false])  # =>
    'truthy' if (a, b = *[false, true])  # =>

Post by dkarapetyan » Fri, Jul 22, 2016, 1:19 AM UTC

pmarreck wrote: post #68

dkarapetyan wrote: post #66

Earlier quoted context omitted.

Because I like optional types. I don't like the type system dictating the entire design.

I like optional types as well, but more because I'm lazy. The Elm and Haskell people are not complaining about types, and given that every function takes SOMEthing (of some implicit type) and usually spits out SOMEthing (of some implicit type), I can hardly see how it will "dictate the design" more than create a bit more validation code.