M0036.03 Flavors and standard invalidation
On 2012-08-28 08:25:48 -0400, Michel Hack wrote:
> The argument that we can always deal with this issue later
> does not work, because it would INVALIDATE a standard that
> does not allow for the possibility of multiple flavours.
Well, a new standard (a revision) always invalidates the previous
standard. What really matters is that a revision of a standard
shouldn't introduce requirements under which a program written
for the old standard could no longer behave like before with the
new standard.
IMHO, a set-based interval program would still behave in the same
way if flavors are introduced in the future, assuming that the
implementation uses the set-based flavor. Or could you show an
example for which this would not be the case? (If you can find
one, I think there's something buggy about flavors.)
However if flavors are specified in the first standard and if some
mistake (currently not visible due to the lack of an implementation)
is made with the flavor specification, fixing it in the future could
introduce incompatible changes, and this would be bad.
Now, perhaps a text about flavors could be added if it is informative
only.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)