@indi, thanks for the links, it helps. On the "interval" only the length now is my concern, since the type name will force at some degree the variables names (which usually follows the type consciously or unconsciously ) and which makes lines of code longer which in math calculations matters (formulas long themselves). As for "other developers" here is the recent quote "The range here drives me mad, since range is a well-known term in C++ word like vector and I assume this way of usage". So they are fine with other vectors, they are surprised when range is totally different thing.

@indi, I see. Would the interval have a shorter nickname like int (joking here), I would be happy. Why this couldn't be bounds or extents? Still long, but what wrong with them? And... my problem is not with namespaces and language itself, my problem is with communication with other developers. When they hear range that think about std::ranges::range; when they see in code range they assume I am crazy enough to write somewhere in header file using namespace std::ranges;.

On the float my point is that I use this type mostly with float variables and if they could cause any issues I would be happy to know about it beforehand. I can't just forbid float usage, since range<float> is very valuable for me.

I am not sure about the min <= max invariant, since before I start search for a range in a loop of values, often I have to initialize in exactly in the opposite way: range<float> range = { std::numeric_limits<float>::max(), std::numeric_limits<float>::lowest() }; so that I can find max and min values from the array of values in the loop later. This could be solved with 'bool valid()' method which gives true if min <= max (it is not always possible to initialize them by the first element of the set, since the set could miss it).

It is worked always for me for defined floats (not for NaNs, -inf, etc). What could be the trap? In which case except this non-values, float could show its not strongly-ordered behavior? Can you show an example, please?

Thank you for the input. I am concerned with 'limits' because of two reasons which fall into one: C++ std library already has std::limits which could lead to confusion during discussions and which is more important it gives people some kind of sense/assumption that limits in C++ are for the border values not for the data set, but for the types themselves (like min(), max(), lowest(), etc.). So this is language-term-intersection-risky and still risky for misunderstanding.

@TobySpeight, thank you, it keeps my original question, so no any objections from my side. My focus here is to make sure that I've not missed some obvious name which is widely used in industry by C/C++ developers and became de facto standard for this. I would be curious if nobody uses the same structure, as well.

@ChrisWue, thank you for the update. I applied the same workaround in my code (when I met the problem). On your comment on workaround; of course, it is a kind of personal sense,but I consider conditional expressions (even for boundary conditions) as workarounds, especially when they come in the expensive loops (hard to read, takes extra time to execute). The code doesn't contain workarounds when it is transparent to any special cases. In case this would be incorporated into the calculations before the loop or disappear at all by changing the algorithm, I wouldn't consider this as a workaround.

Just check you code for area == 1.0f; the result will be wrong.

@michar, this "small note" makes the code above wrong and buggy with hard to catch out-of-range bug; funny for accepted and many times upvoted code. Anyway, are you aware of good examples of the fix you have mentioned? All ways I can see so far are workaround-style and I don't like them.

Thank you again for the review. I've posted the Rev3 with my comments, answers and questions. I am especially interested in your help with answers to my questions on functional decomposition and my concerns in Rev.3. Could you please take a look?