do i need any contracts to emulate ``` ...

# language-evolution

[jimn]

do i need any contracts to emulate

if (!buf.hasRemaining() || read == -1) createWriteNode(buf.flip()) else null

with

infix operator fun <T> Boolean.rem(s: T) = { s }.takeIf { this }?.invoke()
...
            (!buf.hasRemaining() || read == -1) % createWriteNode(buf.flip())

to guarantee that s doesn't fire before comparison?

i actually prefer

inline val <reified T> T.`⟲`  get() = { this }
inline infix operator fun <reified T> Boolean.rem(s: T) = s.`⟲`.takeIf { this }?.invoke()

as the style matches the idioms i use in in prior art but i just don't quite find the langauge lawyer parts i need to trust bytebuffer ops to this one, it has worked for more mundane ternary targets leading up to this but bytebuffers have effects

[Joffrey]

It's already too late in any case if you pass the expression to the function. Wrapping it in a lambda inside the function will not defer the evaluation, because it has already been evaluated. You woud have to pass it as a lambda in order to get the "lazy" effect you want

[Joffrey]

What is so bad about if (cond) value else null ?

[jimn]

i actually did do lazy ?.value but its syncronized, though perhaps there is some contract magic to learn from

[jimn]

as to why do i like terse code? that's not a debate anyone can win

[jimn]

s%foo?:bar  
if(s)foo else bar 
          [-----]

[Joffrey]

You would likely have 4 more spaces in real life code for your first line if you want to distinguish the different expressions in the compact syntax:

s % foo ?: bar
if(s) foo else bar

And using unconventional syntax with custom operators adds cognitive load to the reader as opposed to a simple standard if expression, which I personally don't find worth the saved 4 spaces (then it's a matter of opinion so there's not much to debate).

Maybe you could get away with the lazy execution problem thanks to inlining, as you did in the second version, but I would need to confirm that, as I'm not sure whether an intermediate variable for the function argument would be generated or not, and I'm afk right now so I can't test it.

If it doesn't save you from evaluating, you would have to wrap the passed value in braces when calling your operator, which would make it the same length as the if-else version

[jimn]

creating a lambda crosses some kind of corner case.