Re: textToIntevsal(s) and exceptions
On 2015-03-24 16:59:04 +0100, Marco Nehmeier wrote:
> Am 24.03.2015 um 15:56 schrieb Vincent Lefevre:
> >I would see the inheritance in the other way round: a bare interval
> >can be regarded as a particular decorated interval, with the newDec
> >embedding. Therefore bare_interval would be inherited from
> >decorated_interval.
After some thoughts, the notion of bare interval is already overloaded.
It could mean a decorated interval with implicit decoration, typically
for use as input, and for which applying newDec would make sense.
But it could also mean an interval just as a set, e.g. produced with
intersection or convexHull, for which an implicit decoration doesn't
make sense.
> I only pointed out that there are some dangers if we recommend
> implicit conversion or inheritance like Oliver. With explicit type
> conversion we have clearly defined points in the source code of the
> users where conversions will be performed.
Yes, implicit conversions are often error prone, but this is mainly
due to overloaded types. An example is C, where unsigned int can be
either used for unsigned / modular arithmetic or because one knows
that the value is nonnegative (and unsigned int provides one more
bit compared to int); the problem is that a signed integer type can
be implicitly converted to an unsigned type even in the latter case,
with the effect of changing the value (seen as an integer).
Now, this is mainly a language issue, and P1788 can't do anything
about that (except by defining two different types corresponding to
the current bare intervals: those for which promotion to decorated
interval would make sense, and those for which this promotion would
be forbidden).
For interval *literals*, promotion is less a problem since literals
are normally used as input.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)