Limitations and workarounds to expressions defining size of an array

[Casey Carter]

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."

 

[Tim Rentsch]

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.

 

[Tim Rentsch]

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/wg14/www/docs/dr_261.htm

 

[Keith Thompson]

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/wg14/www/docs/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.

 

[lawrence.jones]

"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.