Proposal: Allow a training `=` on any var infix fu...

# language-proposals

[Ruckus]

Proposal: Allow a training = on any var infix function that returns the receiver's type (or compatible):

// Current
var superAwesomeNumber = 5
superAwesomeNumber = superAwesomeNumber shl 3

// New
var superAwesomeNumber = 5
superAwesomeNumber shl= 3

It would be nice for long chains of bitwise operators, but it could also be nice for any infix function. It is especially appealing when you use very descriptive names.

[Ruckus]

This is similar to an earlier proposal of allowing ! prefix on any infix function that returns Boolean, but I'm not sure what happened with that proposal.

[orangy]

Any other use cases besides shifting?

[orangy]

It applies only to infix functions that have their receiver of the same type as return type (or compatible in some way)

[hudsonb]

I'd rather see real bitwise operators 😀

[hudsonb]

or= and and= would also be use cases

[Ruckus]

@orangy Sure. All the bitwise operators layers and= mask, flags or= newFlag. I also have some custom number infix functions it would be nice to use like currentInnerRatio pMod= 9.0 and colorOffset pingPong= upperBound

[Ruckus]

@hudsonb I agree, but this could apply to more than just bitwise. I just happend to be using a lot of them at the moment 🙂

[Ruckus]

Like many of my proposals, I haven't thought through all the edges, so I'm not sure if this is a good idea overall. One possible problem would be that you couldn't easily override it like you can with operators (+=, -=, etc.), so it may feel a little incongruous.

[Ruckus]

@orangy

It applies only to infix functions that have their receiver of the same type as return type (or compatible in some way)

Indeed, that's what I meant by "variable's type". I've updated it.

[dalexander]

I have a hard time visually parsing superAwesomeNumber shl= 3 as something other than (superAwesomeNumber shl)= 3 so I think if this proposal is accepted I’d like to make sure that the syntax highlighting is distinct in the IDE.

[elect]

still much better superAwesomeNumber <<= 3

[elect]

I find it much faster to read because it's not literal

[Ruckus]

@elect I agree, but this proposal has nothing to do with bitwise operators. That is a separate proposal that had been in discussion for quite a while.