There are some situations when this code would be great to work:
foo = "foo"
foo &= .upcase if rand > 0.5
pp foo
It works for String and Number concatenation, however, + and - are just methods as well, so why not letting the syntax be more sweet with &=?
Just to be clear, the code above should expand to
foo = foo.upcase if rand > 0.5
WDYT, Crystallers?
Wouldnât it make code harder to parse at least for humans?
Compare this straightforward to expand example (you donât need to think about right side here, the &= defines the expansion):
left &= right
left = left & right
This is confusing however (the & and . come from different sides, and if there is . at the right side it expands differently now, and whatâs worse the end result is not related to & operator at all):
left &= .right
left = left.right
Just from âlooks goodâ standpoint it feels like your idea to shorten the code can be written as:
left .= right
left = left.right
However the . is not even an operator to begin with.
Using left &.= right probably looks even weirder.
Iâm not a fan of foo &= .something as &= is already an operator:
foo &= expr
foo = foo & expr # expanded
It would be confusing to have the same operator for 2 entirely different things⌠(AND binary operator, and short method calling)
Also left &= .right and @vlazar 's left &.= right looks like a call to left: left(&.=(right)), with the former being a weird typoâŚ
@vlazar left .= right doesnât look ârightâ, we canât see the relationship between left & rightâŚ
Another idea idea would be a = pseudo operator/method that takes a block:
foo = &.upcase
foo = foo.upcase # expanded
I like this syntax because it looks like crystal!! And I think itâs quite easy to guess what it does.
@bew Not sure what you mean by âwe canât see relationshipâ. Visually itâs exactly the same rules as for left += right or any other operator, just ignore the spaces. Well also ignore that . is not an operator:
left += right
left = left + right # expanded
left .= right
left = left.right # expanded (plus spaces removed)
That being said Iâm not sure this is a good idea as removing spaces and ignoring the ânot operatorâ part doesnât feel very consistent.
For your example with foo = &.upcase itâs easy to guess what it does, but &. now has quite clear semantic for blocks and overloading it with expansion syntax for assignment might not be a good idea as well.
Side note: I never made any language or part of it, I would guess there are tons of ways the introduction of some syntax might look very appealing on the surface but complicate language implementation exponentially.
It would be much more interesting to hear opinion on this matter from someone who has expertise on this. Maybe @asterite can chime in here and tell the kids why this is a terrible idea? 
I think left .= right expanding to left = left.right is the most intuitive syntax.
That said, Iâm not sure this is that common or useful. And with this I mean âimplementing it might be easy, but without carefully thinking about it it might interact badly with other features or even prevent us from using that syntax or that operator for something else in the futureâ.
I disagree for left .= right, what I mean by not seeing relationships is that it looks like a call to a top level right method and even worse imo it looks like a call to =: left.=(right), which doesnât make sense.
I agree .= would be kinda consistent with += expension logic, but to me itâll do much more bad than good because itâs inconsistent / conflicts with the current call syntax
Yeah. Syntax is very important, thatâs why we love Crystal. But itâs also very hard and requires careful thinking.
Just to throw that out there:
Ruby has method + ! as a sytax for I will modify my caller.
This could be interpreted without too much of a stretch as such:
a = a.split
a.split!
Theoretically this would remove the ! from being a legal character in method names.
Also, major disclaimer, I have no idea of language design, I have not thought this through at all, and Iâm not even sure I like it all that much, Just though to mention it as a option.
& reminds me of the bitwise operator in an if statement. then when I see the foo &= .upcase part, it makes my head explode 
I really like
foo = foo.upcase if rand > 0.5
itâs just so simple and easier to read (IMO)
IMO this is a non-issue, not worth to solve it. The expanded version is easy to follow, doesnât require to learn any new concepts and thanks to the postfix-if already short and fast enough to write.
I ditto this statement, Iâd need a lot of convincing to include this sugar in crystal, regardless of the syntax.