«

On 2012-09-07 16:04, Keith Thompson wrote:
> This is different than the general permission to provide extensions
> given by 4p6:
>
> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter the
> behavior of any strictly conforming program.
>
> which does (I think!) require a diagnostic for any code that would
> violate a constraint in the absence of the extension.

It's somewhat orthogonal to the issue at hand, but I'm in the mood for
pointless semantic arguments today. I suggest that "any code that would
violate a constraint in the absence of the extension" is necessarily NOT
within the sphere of "any strictly conforming program."

"BartC" <> writes:

> "Tim Rentsch" <> wrote in message
> news:...
>> Keith Thompson <kst-> writes:
>
>>> But where do you draw the line between constant and non-constant
>>> expressions? The authors of the standard already decided exactly
>>> where to draw that line. [snip]
>>
>> More specifically, they have drawn two lines, one representing
>> a minimum set of what are constant expressions, and one
>> representing which constructs are always out of bounds for
>> constant expressions -- kind of a lower bound and an upper
>> bound. And function calls are over the "not allowed" line.
>
> Perhaps it's about time then that the built-in mathematical
> functions were classed as operators, not as arbitrary
> functions. [snip elaboration]

Way more trouble than it's worth. If you want to allow
function calls in constant expressions, it's easier
just to move them from the Constraints part of section 6.6
to the Semantics part of the same section.

Keith Thompson <kst-> writes:

> Tim Rentsch <> writes:
> [...]
>> Expressions that contain a function call and that must
>> be constant expressions are constraint violations and
>> must have a diagnostic issued, regardless of whether
>> an implementation chooses to regard them as constant
>> expressions.
>
> I'm not convinced that's correct. [snip elaboration]

This issue was addressed in Defect Report # 261, which reads in
part:

* If the syntax or context only permits a constant
expression, the constraints of 6.6#3 and 6.6#4 shall apply.

* Otherwise [ie, if the constraints above are not violated],
if the expression meets the requirements of 6.6 (including
any form accepted in accordance with 6.6#10), it is a
constant expression.

* Otherwise it is not a constant expression.

The phrase in []'s is my comment, but I'm confident it's
correct because otherwise the second bullet item makes
no sense. In any case here is the link if you want to
read the whole thing (be warned! some of the examples
flow off the right side of the page):

http://www.open-std.org/jtc1/sc22/wg...ocs/dr_261.htm

Tim Rentsch <> writes:
> Keith Thompson <kst-> writes:
>> Tim Rentsch <> writes:
>> [...]
>>> Expressions that contain a function call and that must
>>> be constant expressions are constraint violations and
>>> must have a diagnostic issued, regardless of whether
>>> an implementation chooses to regard them as constant
>>> expressions.
>>
>> I'm not convinced that's correct. [snip elaboration]
>
> This issue was addressed in Defect Report # 261, which reads in
> part:
>
> * If the syntax or context only permits a constant
> expression, the constraints of 6.6#3 and 6.6#4 shall apply.
>
> * Otherwise [ie, if the constraints above are not violated],
> if the expression meets the requirements of 6.6 (including
> any form accepted in accordance with 6.6#10), it is a
> constant expression.
>
> * Otherwise it is not a constant expression.
>
> The phrase in []'s is my comment, but I'm confident it's
> correct because otherwise the second bullet item makes
> no sense. In any case here is the link if you want to
> read the whole thing (be warned! some of the examples
> flow off the right side of the page):
>
> http://www.open-std.org/jtc1/sc22/wg...ocs/dr_261.htm

"In summary, provided the above points are taken account of, the
Committee does not believe the Standard is ambiguous nor that it is
necessary to modify it to make this clearer."

Clive D.W. Feather wasn't entirely sure what the Standard meant, but
it's not necessary to make it any clearer.

Riiiight.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <kst-> wrote:
>
> "In summary, provided the above points are taken account of, the
> Committee does not believe the Standard is ambiguous nor that it is
> necessary to modify it to make this clearer."
>
> Clive D.W. Feather wasn't entirely sure what the Standard meant, but
> it's not necessary to make it any clearer.
>
> Riiiight.

To be fair, my friend Clive has a penchant for going out of his way to
not be entirely sure what the Standard means. It's a trait that's as
valueable as it is annoying, so we always give his input serious
consideration and we end up agreeing with him more often than not. But
not always.
--
Larry Jones

What a waste to be going to school on a morning like this. -- Calvin