Adding std::is_between/in_range function

[Dan Raviv]

It seems tempting to add an std::is_between/in_range function, which just does

template<class T>
constexpr bool is_between( const T& v, const T& lo, const T& hi )

{

    return std::clamp(v, lo, hi) == v;

}

and obviously a similar version with a custom comparator.

This sort of function isn't available as far as I've seen. It think writing

if (is_between(v, lo, hi))

would be clearer, DRYer and less error-prone than either

if (std::clamp(v, lo, hi) == v)

or the usual

if (v >= lo && v <= hi)

Thoughts?

[Barry Revzin]

Herb's recent comparison paper (http://wg21.link/p0515) proposes properly chaining comparisons, which would let you just write:

if (lo <= v <= hi)

That'd be the best solution, imo.

[gmis...@gmail.com]

Herb's recent comparison paper (http://wg21.link/p0515) proposes properly chaining comparisons, which would let you just write:

if (lo <= v <= hi)

That'd be the best solution, imo.

I personally despise that notation. I'd probably pattern match it and get used to it, but I'd much rather is_between.

I also hate the if (10 <= a) instead of if (a <= 10) style so perhaps it's just something quirky to me.

But is_between gets my vote all the same..

[Jeffrey Yasskin]

is_sorted({lo, v, hi}) will probably work after the Ranges TS.

> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/324fef50-3fc0-4b81-8b14-4ab021e659c9%40isocpp.org.

[Arthur O'Dwyer]

I would never write the "Yoda notation" if (10 <= a), but for range tests I do invariably write

    if (lo <= v && v <= hi)

already. It doesn't bug me to have to write that extra "&& v"; my eyes and fingers basically just ignore it.

Contrariwise, if I saw someone trying to introduce a function like the OP's into my codebase, I'd strenuously object. Why would I take three things that are intrinsically ordered — lo, v, hi — and deliberately write them in the "wrong" order — v, lo, hi? That just seems confusing.

Similarly, since std::clamp doesn't exist in any of my codebases yet, I'm used to writing

    clamped_v = std::min(std::max(lo, v), hi);  // mnemonic: nouns in the order {min max, lo v hi}

...even though I'm aware that in generic code these are currently technically better options due to a snafu in the definition of std::max:

std::min(std::max(v, lo), hi)  // mnemonic: nouns in the same order that std::clamp wants them

std::max(std::min(v, hi), lo)

It would be nice to "fix" std::max, but maybe that's a non-starter because of all the existing code that depends on its current behavior. I'm sure it's been discussed ad nauseam.

–Arthur

[Tony V E]

If ‎you think that we may ever get unified function calls, then it is best to put the 'object' of the function first. 

is_between(v, lo, hi) 

becomes

v.is_between(lo, hi)

Even if you don't think unified functions ever will/should happen, it might still be a good rule for LEWG (and other library designers) to follow, just to increase consistency.

Sent from my BlackBerry portable Babbage Device

From: Arthur O'Dwyer Sent: Wednesday, February 15, 2017 7:08 PM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Cc: gmis...@gmail.com Subject: [std-proposals] Re: Adding std::is_between/in_range function

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bc38f107-e5a4-4132-b16f-041f37a71ea8%40isocpp.org.

[Thiago Macieira]

On quarta-feira, 15 de fevereiro de 2017 10:51:52 PST Barry Revzin wrote:
> if (lo <= v <= hi)
>
> That'd be the best solution, imo.

That will never work for non-primitive types, since operator< and operator<=
can be overloaded and return something other than bool.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center