min/max <? / >? expressions

[TurkeyMan]

This bugs me every few weeks for decades... I still want this just as much as the first say it ever came up for me:

It's really annoying to import a module for min/max, it feels so 'heavy' for such a trivial operation. It's also annoying that they're functions; you have to step-in/step-out etc while debugging code, and they are so frequently used in hot-loops, while calling functions in debug/unoptimised code just slows it down needlessly, even more than unoptimised code already it...

C++ has a non-standard language extension, and I think it's also present in C# that adds a min/max operator. It is this:
a <? b and a >? b, which simply expands a < b ? a : b and a > b ? a : b.
I desperately want these in D... they're just so nice and readable, don't require bulky imports, efficient in debug builds, nicer when working in the debugger, etc...

I know these are all minor nuisances, but the practical result is that I very rarely actually import min/max, and almost always just write the expression out a < b ? a : b, which damages code readability, particularly when a or b are long-ish expressions.

This could be implemented with trivial lowering. It's lame when other languages have nice QOL features that we don't have in D, especially like this which are just cosmetic and pose no threats.

[TurkeyMan]

#20626 ...just trying it on!

[Herringway]

Maybe it's because I don't worship at the altar of C++, but I don't see how these messes of random punctuation are more readable than the status quo.

[TurkeyMan]

Suggesting that x+y*z < object.method(x) ? x+y*z : object.method(x) is a shit thing to read is not worshipping the alter of C++... and it's not even in C++!
I feel like you didn't actually read the text above...

[Herringway]

Suggesting that x+y*z < object.method(x) ? x+y*z : object.method(x) is a shit thing to read is not worshipping the alter of C++... and it's not even in C++! I feel like you didn't actually read the text above...

I feel like you didn't read my post, either. x+y*z <? object.method(x) is ugly. Why the question mark? Is it supposed to be meaningful or was it just a symbol that happened to be available? We should copy the syntax verbatim from a C++ extension because... why, exactly?

[TurkeyMan]

The question mark because it's short-hand for the ?: operator which eliminates the repetition:

x < y ? x : y => x <? y

You don't need to repeat x and y twice...
If you can't see how the question mark is obviously logical... 🤷

[schveiguy]

x.min(y) or min(x, y) Is really the alternative. Yes, you have to import std.algorithm. But I find it very readable.

If we had more ?-based punctuation, it might make sense to tack on, but we don't yet.

Andrei originally also proposed the "elvis operator" ?:, as in x ?: y, as a substitute for x ? x : y which depends on the truthiness of x.

[TurkeyMan]

Suggesting that x+y*z < object.method(x) ? x+y*z : object.method(x) is a shit thing to read is not worshipping the alter of C++... and it's not even in C++! I feel like you didn't actually read the text above...

I feel like you didn't read my post, either. x+y*z <? object.method(x) is ugly. Why the question mark? Is it supposed to be meaningful or was it just a symbol that happened to be available?

It's meaningful, it's logical, and I just explained it twice.

We should copy the syntax verbatim from a C++ extension because... why, exactly?

It's not C++. This isn't in C++. I already said that too.

[Herringway]

Suggesting that x+y*z < object.method(x) ? x+y*z : object.method(x) is a shit thing to read is not worshipping the alter of C++... and it's not even in C++! I feel like you didn't actually read the text above...

I feel like you didn't read my post, either. x+y*z <? object.method(x) is ugly. Why the question mark? Is it supposed to be meaningful or was it just a symbol that happened to be available?

It's meaningful, it's logical, and I just explained it twice.

We should copy the syntax verbatim from a C++ extension because... why, exactly?

It's not C++. This isn't in C++. I already said that too.

Don't complain to me about your choice to reply to the same post twice with the same content.

[TurkeyMan]

🤨

Now I'm just confused...

[WalterBright]

Thanks for posting the suggestion.

I want to underscore an important point. a>b?a:b evaluates a twice sometimes, and b the other times. This is an irksome quality of ?:. Any solution should not have this double evaluation.

Introducing <? and >? as operators seems like a big ask. I use min/max now and then, but not that often. Is it really used so much that it justifies new operators? How far should we go with that? Also, I know implicitly what min/max do. I don't have to remember is it <? or ?<, or what the operator precedence is. It adds more complexity to the language and the specification and the work someone has to go to use it.

I agree that importing std.algorithm.comparison can be a bit heavyweight. That module imports the usual ghastly panopoly of other modules:

import std.functional : unaryFun, binaryFun, lessThan, greaterThan;
import std.range.primitives;
import std.traits;
import std.meta : allSatisfy, anySatisfy;
import std.typecons : tuple, Tuple, Flag, Yes;
import std.internal.attributes : betterC;

But all is not lost. It turns out that the definition of max is trivial:

T max(T, U)(T a, U b)
if (is(T == U) && is(typeof(a < b)))
{
    return a < b ? b : a;
}

I was pleasantly surprised to see that! It's a thing of beauty, ain't it? In fact, it will still work as:

T max(T, U)(T a, U b) => a < b ? b : a;

Who wouldn't be proud to take that to the Prom? As a bonus, it only evaluates each argument once.

As for debugging issues, if it's inlined there's no further issue with that. The same goes for using pragma(inline, true) for non-optimized builds.

Therefore, unless I made an egregious error in this analysis, I suggest just adding that line to your code.