Closed mpusz closed 10 months ago
- Should we have both solutions?
q.in(si::metre).number()
can replace q.number_in(si::metre)
.
Well, we can also use q[si::metre].number()
now.
BTW, there is one more important difference in behavior between isq::height[m]
and q[m]
. The first one is provided unconditionally, while the second one is available only for non-truncating conversion. Otherwise value_cast<m>(q)
needs to be used.
- Should we have both solutions?
q.in(si::metre).number()
can replaceq.number_in(si::metre)
.
IIRC, the proponents of number_in
suggested removing number
because it's unsafe.
So to get the number you have to specify the unit.
On the other hand, q.number_in(m)
, as of now, has the same constraints as q[m]
.
First, I would like to state that I personally love the syntax that creates a
reference
based onquantity_spec
andUnit
:I wouldn't like to make the above gone.
However, yesterday I wrote the following example in our documentation:
Initially, I provided this operator to entertain myself with this idea and for consistency with the above. However, there are a few significant differences here:
isq::height[m]
is a pure compile-time operation with no runtime overhead. It also never touches the quantity value.q[m]
, of course, creates a new type in compile-time but also involves a runtime value rescaling operation according to the provided new unit. It can also lead to overflows or losing the precision of a quantity value.Even more, we now have a
q.number_in(si::metre)
(#412), which returns a raw value in a provided unit.So here comes the questions:
q.in(si:::metre)
to express runtime behavior and for consistency withnumber_in()
?q[si::metre]
?