NOTE: Intentionally not titled as "defect report", since that doesn't
apply to a working draft. Some parts of this, though, concern parts
which are unchanged from C++03, and thus might well qualify,
separately, as formal defect reports. If the committee feels this
separation is in order, please just let me know.

In the current working draft (n2134) the following wording from n1720,
"Proposal to Add Static Assertions to the Core Language (Revision 3)",
has been incorporated:

  7.? static_assert declaration
  The constant-expression shall be an integral constant expression
  (5.19 [expr.const]). If the value of the expression when converted
  to bool is true, the declaration has no effect. Otherwise, the
  program is ill-formed, causing the implementation to produce a
  diagnostic message (1.4 [intro.compliance]) that includes the text
  of the string-literal, except that characters not in the basic
  source character set (2.2 [lex.charset]) are not required to
  appear in the diagnostic message.

I see some problems with this:

  a) it should talk about convertibility of *the expression* (not
     its value), and should say that the attempted conversion is
     *implicit conversion* (to bool)

  b) if the integral constant expression isn't convertible to bool
     at the point where the static_assert appears (for instance
     because the relevant conversion function is inaccessible) I
     don't think we want the normal diagnostic message (that is,
     the one with the string-literal in it). I'd say something
     along the lines of

       error (ln xyz): "condition of static_assert must be implicitly
       convertible to bool

     would be preferable

  c) is a wide string-literal accepted or not? I made a general DR on
     this, which wasn't forwarded to the committee (as sadly happens
     for a lot of DRs posted on comp.std.c++):


<http://google.com/group/comp.std.c++/browse_thread/thread/cc5d1bba604be224/dbbd46a1d992aa92>

     Note that the defect is even "wider" (no pun intended) now, due
     to n2018, "New Character Types in C++" and n2053, "Raw String
     Literals".

     I'd also mention that a reasonable "transition" implementation of
     static_assert can be provided in C++03; e.g.:


<http://breeze.svn.sourceforge.net/viewvc/breeze/trunk/breeze/meta/static_assert.hpp>

     And it would help, for this goal too, to know whether wide string
     literals are allowed

  d) to my knowledge the standard doesn't require a diagnostic to be
     a message (I think this problem also affects the specification
     of #error); if so, the wording should be tweaked along the lines
     of "if the implementation is able to produce a (textual, vocal,
     or other) message, then it produces... except that characters
     not in the basic source character set may be omitted".

     I'm not sure whether the committee might want to restrict the
     chance to omit characters to text messages only (it wouldn't
     be necessary, I guess, for a vocal message :-))

PS: in the example

  static_assert(sizeof(long) >= 8,
                "64-bit code generation required for this library.");

  the part "sizeof(long) >= 8" would also better be changed to

  "sizeof(long) * CHAR_BIT == 64"
or
  "std::numeric_limits<long>::digits == 63"
or
  "std::numeric_limits< unsigned long>::digits == 64"

--
Genny.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota schrieb:

> In the current working draft (n2134) the following wording from n1720,
> "Proposal to Add Static Assertions to the Core Language (Revision 3)",
> has been incorporated:

[..]

> I see some problems with this:

[...]

>   b) if the integral constant expression isn't convertible to bool
>      at the point where the static_assert appears (for instance
>      because the relevant conversion function is inaccessible) I
>      don't think we want the normal diagnostic message (that is,
>      the one with the string-literal in it). I'd say something
>      along the lines of
>
>        error (ln xyz): "condition of static_assert must be implicitly
>        convertible to bool
>
>      would be preferable

Are you thinking here along the lines of constexpr? Because
otherwise I do not see any reason for inaccessible ICE's or the
validity of (user-defined) conversion functions. There can be
names of entities which are not accessible (e.g. enumerator
names), but this kind of "access violation" should result in an
error message. Even if constexpr has to be taken into account
there should usual ordering of concerns apply, that is access
will be checked *after* name lookup and overload resolution,
so we have the same situation as for inaccessible enumerators
or other constexpr functions/data here, don't we?


>   c) is a wide string-literal accepted or not? I made a general DR on
>      this, which wasn't forwarded to the committee (as sadly happens
>      for a lot of DRs posted on comp.std.c++):

Don't tell me ;-) Although in my case I was surprised that a lot
have been forwarded, but I was not aware of this, because there
was no written statement along the lines of

"MODERATOR'S COMMENT: Forwarded to the C++ committee."

But I won't complain - I'm happy that most have been recognized
as such, so I will repost the most important ones missing at a
later time.

>      Note that the defect is even "wider" (no pun intended) now, due
>      to n2018, "New Character Types in C++" and n2053, "Raw String
>      Literals".
>
>      I'd also mention that a reasonable "transition" implementation of
>      static_assert can be provided in C++03; e.g.:
>
> <http://breeze.svn.sourceforge.net/viewvc/breeze/trunk/breeze/meta/static_assert.hpp>
>
>      And it would help, for this goal too, to know whether wide string
>      literals are allowed

Concerning wide characters: Yes, I think that should be clarified,
but strictly speaking I would say that by speaking of string-literal
wide character sequences are fine, note also that even
asm-definitions, linkage specifications, or _Pragma expressions
must accept those.


>   d) to my knowledge the standard doesn't require a diagnostic to be
>      a message (I think this problem also affects the specification
>      of #error); if so, the wording should be tweaked along the lines
>      of "if the implementation is able to produce a (textual, vocal,
>      or other) message, then it produces... except that characters
>      not in the basic source character set may be omitted".
>
>      I'm not sure whether the committee might want to restrict the
>      chance to omit characters to text messages only (it wouldn't
>      be necessary, I guess, for a vocal message :-))

I just checked N2134 concerning this and I interpret the combination
of 1.3.3

"diagnostic message
a message belonging to an implementation-defined subset of the
implementation's output messages."

and 1.3.15

"If a program contains a violation of any diagnosable rule or an
occurrence of a construct described in this Standard as
"conditionally-supported" when the implementation does not support
that construct, a conforming implementation shall issue at least
one diagnostic message[..]"

requires at least one message for diagnosable errors.

> PS: in the example
>
>   static_assert(sizeof(long) >= 8,
>                 "64-bit code generation required for this library.");
>
>   the part "sizeof(long) >= 8" would also better be changed to
>
>   "sizeof(long) * CHAR_BIT == 64"
> or
>   "std::numeric_limits<long>::digits == 63"
> or
>   "std::numeric_limits< unsigned long>::digits == 64"

IMO only the last two are guaranteed to be portable, because
of the object representation/value representation ratio freedom
of long.

Greetings from Bremen,

Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1173986875.426835.50050@l77g2000hsb.googlegroups.com>,
 "Daniel Krugler" <daniel.kruegler@googlemail.com> wrote:

> >   c) is a wide string-literal accepted or not? I made a general DR on
> >      this, which wasn't forwarded to the committee (as sadly happens
> >      for a lot of DRs posted on comp.std.c++):
>
> Don't tell me ;-) Although in my case I was surprised that a lot
> have been forwarded, but I was not aware of this, because there
> was no written statement along the lines of
>
> "MODERATOR'S COMMENT: Forwarded to the C++ committee."
>
> But I won't complain - I'm happy that most have been recognized
> as such, so I will repost the most important ones missing at a
> later time.

Fwiw I'm trying to keep the inter-mailing LWG list up to date here:

http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active
.html

Sometimes I get a week or two behind, but if it is a library issue, and
you think it should be there and isn't, I don't mind a ping.  And since
this is a completely unofficial posting, if I mess up your report, or
you decide you want to change it for any reason after you see it at the
above link, and prior to the mailing, just let me know.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Gennaro Prota" <gennaro.prota@yahoo.com> napisal w wiadomosci news:218iv2dgjhak63j2tfh97ln8uvubk881l7@4ax.com...
> NOTE: Intentionally not titled as "defect report", since that doesn't
> apply to a working draft. Some parts of this, though, concern parts
> which are unchanged from C++03, and thus might well qualify,
> separately, as formal defect reports. If the committee feels this
> separation is in order, please just let me know.
>
> In the current working draft (n2134) the following wording from n1720,
> "Proposal to Add Static Assertions to the Core Language (Revision 3)",
> has been incorporated:
>
>  7.? static_assert declaration
>  The constant-expression shall be an integral constant expression
>  (5.19 [expr.const]). If the value of the expression when converted
>  to bool is true, the declaration has no effect. Otherwise, the
>  program is ill-formed, causing the implementation to produce a
>  diagnostic message (1.4 [intro.compliance]) that includes the text
>  of the string-literal, except that characters not in the basic
>  source character set (2.2 [lex.charset]) are not required to
>  appear in the diagnostic message.
>
> I see some problems with this:
[snip]
>  b) if the integral constant expression isn't convertible to bool
>     at the point where the static_assert appears (for instance
>     because the relevant conversion function is inaccessible) I
>     don't think we want the normal diagnostic message (that is,
>     the one with the string-literal in it). I'd say something
>     along the lines of
>
>       error (ln xyz): "condition of static_assert must be implicitly
>       convertible to bool
>
>     would be preferable
>

This remark is void: an integral constant expression is implicitly convertible to bool.
In other words, an expression containing a conversion function is not a constant expression.
And neither is sizeof an invalid expression, e.g. an inaccessible data member.
If the expression itself is ill-formed, the error message provides an explanation why.
If the expression is of an unsupported type, the error message says just that.
If the expression is false, the custom error message appears.
It is all neat and clean.
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]