Re: Motion 46: finalise interval literals, amendments
Dmitry, Michel, Richard & others
Also Christian, as I have a conformance question.
Views ASAP please, on the two alternatives mooted for (A), so we can proceed to the vote.
(A)
On 9 Jul 2013, at 07:59, Dmitry Nadezhin wrote:
> Perhaps, there is an issue with leading zeroes in ratNumLit .
> Let's take ratNumLit "010/011". It's value is 10/11 .
> However, some languages treat leading zero as start of octal number,
> so some users may expect that the value of the literal is 8/9 .
>
> Will it be safer if we forbid leading zeros in ratNumLit ?
I don't think it's a good idea to restrict all implementations because of a feature of one language. Someone would come along with another unusual language feature and there would be no end to it.
Maybe, after the definition of the 4 kinds of number literal, add
> An implementation may make language-defined restrictions on the form of
> number literal.
> [Example. Some languages treat leading zero as the start of an octal number.
> They may forbid p and q of the p/q form to start with a zero.]
An alternative is Richard Fateman's suggestion (9 July): Let p and q be "integer literals" (a new category in this subclause) of the host language, instead of being decimal strings. I think that removes from 1788 the responsibility of avoiding a syntax clash. And if someone wants to write p and q in octal or hex, etc., that's OK if the host language allows it.
(We must require that p & q don't themselves contain '/'.)
(B)
What about restricting the size (length) of p and q? IMO an "industrial strength" implementation should not do so. But a small implementation such as for university student use may well wish to.
I think this can be handled within the conformance clause. Christian, am I right one can use the notion of "conformance levels", so one can specify a subset of requirements that are what a "small" implementation must satisfy?
John Pryce