N4433 is missing a huge opportunity to be a general interface to the pretty=
-printer that any reasonable implementation must already use to generate di=
agnostic messages.

As I was saying to Walter Brown while he was drafting N3928 (Dec =E2=80=991=
3 =E2=80=93 Jan =E2=80=9914, the below is partially quoted in that proposal=
):

> The standard does not need to guarantee anything about the presentation o=
f diagnostic messages, and in general it does not try (and that's a very sw=
eeping generalization). Note that nobody proposed that the line number and =
file name should go into the diagnostic, as they do with the runtime assert=
() macro: every implementation already provides this information for static=
_assert, as with every other diagnostic before link time. Likewise printing=
 at least the line of source code containing the static_assert keyword is p=
retty much universal, and this usually includes the constant expression.

>=20

> Ideally static_assert should print not one optional message but a variadi=
c list of constant expressions, strings, and typenames. All implementations=
 already have facilities to print types and values in diagnostics, and the =
lack of this feature in static_assert often requires falling back on older =
template tricks.

The compiler is going to have an easier job of formatting values and catena=
ting message strings than a string metaprogramming library.

A subsequent email goes into more depth. My intent is to finesse this into =
a proposal, ideally with a prototype:

> Just as another data point in favor of minimalism, Clang does not transla=
te newlines, which are part of the basic source character set, but relays t=
he \n escape code to the user. GCC on the other hand does translate \n, and=
 furthermore beeps when you give it \a. The standard is ambiguous because "=
the text of the string-literal" could refer to either the spelling or the v=
alue.
>=20
> Here is some suitable standardese, although I'm afraid it makes much broa=
der changes. If this is too much to include in the present proposal, I othe=
rwise ask that the section (or its attribution to me) be removed.
>=20
> static_assert-declaration:
>    static_assert ( conditional-expression exposition-list[opt] ) ;
> exposition-list:
>    exposition-list[opt] , exposition
> exposition:
>    template-argument
>    string-literal
>=20
> Replace paragraph 4 as follows. The use of "should" is intended to repres=
ent a recommendation without specifying a formal requirement (ISO/IEC Direc=
tives Part 2, table H.2):
>=20
> If the <i>conditional-expression</i> in a static_assert-declaration is a =
well-formed constant expression, it is contextually convertible to bool, an=
d its value when so converted is true, the declaration has no effect. Wheth=
er the exposition-list is processed, such as to instantiate macros and dete=
rmine its well-formedness, is implementation-defined. Otherwise, the progra=
m is ill-formed, and translation of the static_assert-declaration should pr=
oduce exactly one diagnostic message representing the sequence of <i>exposi=
tions</i> to the user, without mentioning problems intrinsic to their evalu=
ation. [Note: A conforming implementation may completely ignore expositions=
, or diagnose their faults, but should not.] [Example:
>=20
> static_assert(sizeof(value_type) >=3D 8, "value_type is type ", value_typ=
e, " with size ", sizeof (value_type),
>    " which may provide insufficient numeric range." );
> // Diagnostic output: "static_assert failure, foo.h:42: value_type is typ=
e short int, with size 2, which may provide insufficient numeric range."
>=20
> - end example ]
>=20
> -- End standardese; begin explanatory proposal text. --
>=20
> This is designed to support three models of diagnosis, which are not mutu=
ally exclusive:
>=20
> 1. A failed static_assert suppresses further diagnostic messages from its=
 scope (e.g., a class template or instantiation thereof) by setting a suppr=
ession flag. The flag may be unconditionally set before the condition is pr=
ocessed and unset upon the condition's successful evaluation.
> 2. The static_assert condition controls translation and output of the exp=
osition-list.
> 3. Neither of the above; static_assert is treated as any other declaratio=
n and its subcomponents are translated before it. This is the status quo.
>=20
> In any case, an implementation supporting more than just string literals =
must handle the case where an exposition is argument-dependent but the cont=
rolling expression is not. The whole declaration then becomes dependent.


Note that the last complication applies to N4433 too.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.