It's got a nickname of the Elvis Operator and is a shortening of the ternary operator.
In your example it would detect an 'empty' openOffset and give it a value of 95. If openOffset had a value, it goes untouched. In other words, it's a way to apply a preset to 'value'. That 'openOffset' is being tested for "true" -- groovy true.
You're right, of course, but can I just vent a bit that IMHO it would be so much better if the Elvis operator semantics (or maybe Groovy truth in general?) didn't evaluate a 0 value as false for numeric types.
It makes for different structure of logic expressions for conditionals between numerics and every other type, and in my experience often makes code more complicated that could otherwise have be very compact due to the elegant concept of the Elvis operator.
I know if I'm checking for and handing a zero value rather than just a null check, and I usually do it explicitly with a conditional or as a switch case if there is a range of values. Having the result being ambiguously either 0 or null almost encourages the type of bugs that @braveneldescribed.
I've seen this a lot (maybe in ported ST code?) and wonder why the dev didn't just use device.displayName instead, which is probably exactly that implementation.
Yeah, there are times when it is handy, then there are times when it makes it easy to introduce unintended bugs. It's not just numeric types, either--empty strings, empty lists, empty maps, etc., will all evaluate as false.
One coder's pitfall is another coder's power. Having coded in Groovy daily for several years, I can attest to the power part, and wouldn't want to change Groovy truth. I continue to be amazed at the depth lurking in Groovy, and I'm sure I have not yet plumbed all of those depths. My code today does not resemble the way it was years ago. Elvis operator is in constant use, but only rarely does the 0 being same as null issue arise. It allows 0 to be used intentionally more than it creates the ambiguity. As an old CS professor told us, there are only 3 numbers that matter: 0, 1, and any other number.
I was taught the same thing. Then I learned the additional enormous value of null checks when writing object oriented code, which changes the game when new innovation brings about an interesting operator like the Elvis operator in Groovy.
Anyway, I think we're at a point of "agreeing to agree" on this topic. 8)
I might be misunderstanding you, but that's not what I meant; my point is that the two lines are not (necessarily) equivalent in outcome. So I meant that if you expand your example into a full script and use a value for value that is not "Groovy true," like a zero, an empty string, empty list or map, or false, then you'll get different output in both cases:
def value = 0
def valueCaseNull = "surprise!"
x = value == null ? valueCaseNull : value
println x // prints 0
x = value ?: valueCaseNull
println x // prints "surprise!"
The only case they are equivalent is when the value is, in fact, null, and the issue I was trying to point out is that this confuses new-to-Groovy programmers sometimes since this is different from, say, Java. This is the point of confusion a couple of us addressed above.