Proposed resolution:

1. Edit [numeric.limits.members] around p60 as indicated:

   static constexpr bool is_modulo;
   

   -60- True if the type is modulo.(footnote) A type is modulo if, for any operation involving +, -, or * on values of that type whose result would fall outside the range [min(), max()], the value returned differs from the true value by an integer multiple of max() - min() + 1.

   -??- [Example: is_modulo is false for signed integer types ([basic.fundamental]) unless an implementation, as an extension to this International Standard, defines signed integer overflow to wrap. — end example]

   -61- On most machines, this is false for floating types, true for unsigned integers, and true for signed integers.

   -62- Meaningful for all specializations.

[ 2016-06 Oulu ]

Added rationalization for changes. Moved to Ready.

Friday: status to Immediate

[ 2016-06, Oulu ]

We believe that the notes about unsigned integer types and floating point types are already evident from what the standard describes and should be removed. Furthermore the suggested note for signed integer types really shouldn't refer to a footnote in the own document, because footnotes have no stable identifiers. The below given revised resolution has been changed accordingly.

[ 2016-05-21 Melissa Mears comments and provides improved wording ]

GCC and Clang have -fwrapv and MSVC (as of a May 2016 preview build) has /d2UndefIntOverflow- as compiler command line flags to define signed integer overflow as wrapping. Such implementations can't set is_modulo to true for signed integer types when these options are enabled, because if translation units using opposite settings were linked together, the One Definition Rule would be violated.

Previous resolution [SUPERSEDED]:

1. Edit [numeric.limits.members] around p60 as indicated:

   static constexpr bool is_modulo;
   

   -60- True if the type is modulo.(footnote) A type is modulo if, for any operation involving +, -, or * on values of that type whose result would fall outside the range [min(), max()], the value returned differs from the true value by an integer multiple of max() - min() + 1.

   -??- [Note: is_modulo is true for unsigned integer types ([basic.fundamental]). — end note]

   -??- [Note: is_modulo is false for signed integer types ([basic.fundamental]) unless an implementation, as an extension to this International Standard, defines signed integer overflow to wrap as specified by the reference mentioned in footnote 217. — end note]

   -??- [Note: is_modulo is false for floating point types on most machines. — end note]

   -61- On most machines, this is false for floating types, true for unsigned integers, and true for signed integers.

   -62- Meaningful for all specializations.

[ 2015-05-05 Lenexa ]

Marshall: I will contact the submitter to see if she can re-draft the Proposed Resolution

Previous resolution [SUPERSEDED]:

1. Edit [numeric.limits.members] around p60 as indicated:

   static constexpr bool is_modulo;
   

   -60- True if the type is modulo.(footnote) A type is modulo if, for any operation involving +, -, or * on values of that type whose result would fall outside the range [min(), max()], the value returned differs from the true value by an integer multiple of max() - min() + 1.

   -??- [Note: is_modulo shall be true for unsigned integer types ([basic.fundamental]). — end note]

   -??- [Note: is_modulo shall be false for types for which overflow is undefined on the implementation, because such types cannot meet the modulo requirement. Often, signed integer overflow is left undefined on implementations. — end note]

   -61- On most machines, this is false for floating point types, true for unsigned integers, and true for signed integers.

   -62- Meaningful for all specializations.

[ 2014-12 telecon ]

HH: agree with the proposal, don't like the phrasing
AM: second note feels a bit wooly
WB: not even happy with the first note, notes shouldn't say "shall"
JW: the original isn't very prescriptive because "on most machines" is not something the standard controls.
AM: "On most machines" should become a note too?
AM: first note is repeating something defined in core, shouldn't say it normatively here. Change "shall" to "is"?
MC: don't like "signed integer overflow is left undefined" ... it's just plain undefined.
AM: implementations can define what they do in that case and provide guarantees.
WB: in paragraph 61, would like to see "this" replaced by "is_modulo"
AM: Move to Open

The seemingly non-normative (?) paragraph 61 (referring to N3936) describing how "most machines" define std::numeric_limits<T>::is_modulo in [numeric.limits.members] appears to have some issues, in my opinion.

-61- On most machines, this is false for floating types, true for unsigned integers, and true for signed integers.

Issues I see:

1. Very minor: change clause 2 to "this is false for floating point types". Other uses of the term say "floating point types" rather than just "floating types" — see nearby is_iec559, tinyness_before, etc.

2. is_modulo must be true for unsigned integers in order to be compliant with the Standard; this is not just for "most machines". For reference, this requirement is from [basic.fundamental] paragraph 4 with its footnote 48.

3. Depending on the definition of "most machines", is_modulo could be false for most machines' signed integer types. GCC, Clang and Visual Studio, the 3 most popular C++ compilers by far, by default treat signed integer overflow as undefined.

As an additional note regarding the definition of is_modulo, it seems like it should be explicitly mentioned that on an implementation for which signed integer overflow is undefined, is_modulo shall be false for signed integer types. It took bugs filed for all three of these compilers before they finally changed (or planned to change) is_modulo to false for signed types.