
Ruby adds experimental support for Rightward assignments - matagus
https://blog.saeloun.com/2020/08/31/ruby-adds-experimental-rightward-assignment.html
======
ericpauley
To me this seems like a clear loss. The syntax is (as far as I can tell)
strictly more verbose than the existing assignment syntax. Ruby is already
plagued by a million-and-one ways to do everything, but at least in other
cases simplicity (à la zen of Python) trades off for brevity.

~~~
drusepth
I don't particularly like the idea of rightward assignment (although the
syntax itself seems fine to me), but the "million-and-one ways to do
everything" is the biggest reason I strongly prefer the language over more
"constrained/limited" languages like Python. In those terms, this seems like a
definite win for the language (and those who choose to use it) for me.

------
adrianmonk
Another language that supported this was Northern Telecom's PROTEL
([https://en.wikipedia.org/wiki/Protel](https://en.wikipedia.org/wiki/Protel))
from the 1980s.

The operator is written "->" and is informally called a "gazinta" ("goes
into").

------
werdnapk
A better example IMO is...

Before:

    
    
      result = case value
        when 5
          ...
        when 4
          ...
        end
    

After:

    
    
      case value
      when 5
        ...
      when 4
        ...
      end => result
    

The latter allows for some nicer formatting I think.

~~~
satisfaction
At the expense of increasing the complexity to read code.

~~~
amw-zero
How is the complexity increased?

~~~
mypalmike
Complexity increase from reading it has.

~~~
satisfaction
Laughed at this I did.

------
rubyn00bie
Does sort of make a hash in Ruby more confusing to the untrained eye (unless
the hash rocket is totally dead, I haven't written Ruby since like the 2.3
days):

{ "age" => age, "name" => name }

I like the _idea_ a lot. It'd probably allow for some nice functional
_looking_ code, but that's also the problem... it'd only _look_ functional.
And I think without VM/compiler/runtime support of functional programming it's
pretty much a big waste of time.

I can use piece shit for a shoehorn; doesn't mean I should.

~~~
Tainnor
No, the hash rocket still exists. However, if you use symbols as keys, you can
replace ":foo => bar" with "foo: bar". Many people, of course, use hashes with
symbols as keys, but whenever you don't, you still need to use the hashrocket
syntax.

------
netsectoday
Rightward assignment with a hash rocket?

I've been using ruby for a decade and I don't get why this is necessary (or
even good).

------
jjgreen
Doesn't this introduce an ambiguity?

    
    
        def foo(*arg, **kwarg)
          puts "#{arg}/#{kwarg}"
        end
        b = 'meh'
        foo(:a => b)
    

Now this produces

    
    
        []/{:a=>"meh"}
    

But with right-assign

    
    
        [:a]/{}
    
    ?

~~~
baash05
Oh. The bugs that this would produce. And spotting it visually would be killer

------
mathw
I get why you'd want it, but I'm not sure they should be reusing => for it,
since that already means something in Ruby.

~~~
arnvald
Yeah, I also start getting confused by reusing of the syntax. Now there's also
a proposal to use { 1, 2, 3 } to represent sets - but {} is already used for
blocks of code and for maps, so now that will be essentially a 3rd use case
for curly braces.

On the other hand Ruby has already such a extensive syntax that it's hard to
come up with something else that would not already be taken. -> represents
lambda, >> is a valid method name, etc.

------
jaredcwhite
For simple one-line expressions, this doesn't seem to offer much. However,
looking at multiline statements with FP-style or conditional logic, this can
definitely improve the flow and visual rhythm of the code.

------
baash05
This is so ugly. Already we have things like AND vs && or tailing if's that
don't quite work like three line if's or how scoping do..end vs {} is ever so
slightly different.

I'd wonder how the right assignment would work differently. What small gotcha
would it create.

I also wonder how my co-workers would take it, if I started using it.. Or if I
figured out how it was different and used it for the once case that it worked.

For me. having a million ways to do something leads to slower dev time. More
context I'd need to load.

------
scarmig
Why do most languages use right-to-left assignments? Is it purely a matter of
path dependence? I guess also that binding a value to a name usually indicates
that you'll use the name later on, and having the name on the LHS makes for a
better UI for looking up the value the name is bound to.

On an unrelated side note, I've always thought "=" was a huge mistake in
language design, confusing countless people who are coming into programming
who reasonably mistake it for equality. I don't know why it won over ALGOL-
style ":=".

~~~
dragonwriter
> On an unrelated side note, I've always thought "=" was a huge mistake in
> language design, confusing countless people who are coming into programming
> who reasonably mistake it for equality. I don't know why it won over ALGOL-
> style ":=".

Probably because adding a colon to an equality sign doesn’t clarify the
meaning at all.

Had Algol (as some less widely influential for other reasons languages have)
adopted something that more clearly represented movement into the variable
being assigned like:

    
    
      a <- 25
    

Maybe it would have won out over “=" for assignment.

~~~
lioeters
I considered such an assignment operator for a little language I was
developing, but there was an ambiguity between this:

    
    
      a <- 25
    

and this:

    
    
      a < -25
    

Since everything was an expression in the language, the latter would evaluate
to a boolean. In the end I just went with "=" for assignment, and "==" for
equality.

------
jbverschoor
I’d rather have changes to type safety, performance, or even a compiled
binary. Or a merger between crystal and interpreted mode

------
lioeters
In a totally different context (but with same semantics), it's known as the
ChucK operator, or "chucking".

[https://chuck.cs.princeton.edu/doc/language/oper.html](https://chuck.cs.princeton.edu/doc/language/oper.html)

------
paozac
Could this be an initial step towards elixir-like chaining?

"foobar" => upcase() => x

------
syspec
Is there a place we can voice our concerns over this move.

I was just teaching Ruby to someone learning to code. I have to admit because
all popular languages use leftward assignment it was one less thing to teach.

=> is pretty loaded as it is

~~~
baash05
Agreed. And it doesn't really improve anything. The argument that it makes
code easier to read is bogus. Perhaps for people who only work in ruby. I
suspect rubo-cop would have a rule against this a week after it was added.

------
nooyurrsdey
why is this even needed? why introduce something to fix something that isn't a
problem?

------
freen
I’m a fan.

In my limited experience, leftward assignment breaks the “flow” explaining a
program to a novice.

~~~
baash05
The problem is.. most popular languages use leftward assignment. Teaching a
noob this would make other languages harder to read. I can switch from Java,
to c++ to ruby.. My 9 year old figured out the leftward assignment. It feels
like a change for change sake.

