[limits] Integrate section [limits.numeric] into section [numeric.lim… #1159

jensmaurer · 2016-11-30T18:53:20Z

…its].

Fixes #785.

tkoeppe · 2016-11-30T19:01:56Z

This would be a nice cleanup. @jwakely, @zygoloid, any objections to the loss of a stable name?

jwakely · 2016-11-30T19:58:21Z

Fine by me.

W-E-Brown · 2016-11-30T20:55:12Z

This cleanup seems to lose the introductory nature of the first paragraph. Perhaps let's promote the original [limits.numeric]/1 to [limits]/1 instead of moving it so far down?

…

On Nov 30, 2016, at 12:53 PM, Jens Maurer ***@***.***> wrote: …its]. Fixes #785. You can view, comment on, or merge this pull request online at: #1159 Commit Summary • [limits] Integrate section [limits.numeric] into section [numeric.limits]. File Changes • M source/support.tex (68) Patch Links: • https://github.com/cplusplus/draft/pull/1159.patch • https://github.com/cplusplus/draft/pull/1159.diff

jensmaurer · 2016-11-30T22:48:56Z

@W-E-Brown: Hm... But the introductory sentence in the first paragraph only mentions numeric_limits, but the synopsis also has float_round_style and float_denorm_style. At this point, it's not clear these are related to the numeric_limits template. That said, I do admit there is little besides numeric_limits in the [limits] section. 18.3.1 already has an introductory sentence that says " specs follow".

Other opinions?

tkoeppe · 2016-11-30T23:34:13Z

The entire structure of 18.3.2 is weird. Anywhere else in the Standard we would structure it like this:

18.3.2: Numeric something something
- 18.3.2.1: Header <numeric> synopsis
- 18.3.2.2: Class template numeric_limits
  - Class template definition
  - 18.3.2.2.1: numeric_limits members
  - 18.3.2.2.2: numeric_limits specializations
- 18.3.2.3: Type float_round_style
- 18.3.2.4: Type float_denorm_style

That is, the synopsis is the first sibling in a subclause that describes the things that are listed in the synopsis. That's how we do it for most other library components. A "General" section could optionally precede the synopsis, but only if there's something useful to say. (I think the origin of "General" sections lies in the ISO drafting directives which say never to have "mixed" content in a subclause, i.e. paragraphs and sub-subclauses.)

tkoeppe · 2016-11-30T23:38:15Z

In a hypothetical world, and given that we now have full synopses for the C library, I could even imagine the following structure:

18.3: Implementation properties of arithmetic types
- 18.3.1: General
- 18.3.2: Header <limits> synopsis
- 18.3.3: Header <climits> synopsis
- 18.3.4: Header <cstdint> synopsis
- 18.3.5: Header <cfloat> synopsis
- 18.3.6: Class template numeric_limits
  - Class template definition
  - 18.3.6.1: members
  - 18.3.6.1: specializations
- 18.3.7: Floating point rounding and extreme values
- 18.3.8: Integer types [##]
- 18.3.9: C library [##]

The last two sections, marked [##], are probably not necessary at all, since their only contained paragraph may as well stay with the synopsis.

jensmaurer · 2016-12-01T08:02:40Z

A mild issue with all the presentation options so far is that float_round_style and float_denorm_style are used in the definition of numeric_limits. It would be good to introduce/explain them before the numeric_limits template. Also, when extracting the synopses, 18.3.6 "C library" becomes empty.

I'd also like to point out that we have a subsection "C library" in clause 27, too, and we just have the synopses under this subsection with a one-sentence "same as in C" statement. Ok, but elsewhere (e.g. in the "strings" clause), the C library stuff is just adjoint to the C++ stuff, without particularly highlighting it's from C.

jensmaurer · 2016-12-01T08:32:50Z

Ok, I've done something along @tkoeppe 's "hypothetical world". I like it now. (Note that I expressly only moved sections, added/removed subsection headings, and fixed cross-references.)

W-E-Brown · 2016-12-01T08:51:03Z

No longer hypothetical, eh? I like it.

- Change order of subsections. - Remove [limits] and [c.limits] subsection headings. - Move descriptions of numeric_limits members and specializations as subsections under the description of the primary class template. - Add sectioning comments to the <limits> synopsis. Fixes cplusplus#785.

jensmaurer · 2016-12-14T18:37:46Z

Rebased.

zygoloid · 2016-12-14T22:26:31Z

source/support.tex

+\tcode{numeric_limits}
+template, specializations shall define these values in such a way
+that they are usable as
+constant expressions.


Do we need this paragraph? What alternative is being excluded here?

Well, there are member functions declared "static constexpr" (such as infinity()), and users can specialize numeric_limits for their own types. Since a function can be declared constexpr, yet not be usable in a constant expression, my guess is that this essentially requires that "T" doesn't access global or volatile variables when copied. (Such a copy is required for the return value of infinity(), for example.)

Ah, this applies to user specializations. Seems weird to put a "shall" on that, but OK.

See also LWG 2833 "Library needs to specify what it means when it declares a function constexpr".

zygoloid

One question, but I'm fine with merging this as-is.

tkoeppe · 2016-12-15T01:30:41Z

Tip for the future: Please always check the overfull box status for your proposed change:

fgrep -e Overfull -e .tex std.log

jensmaurer · 2016-12-16T08:56:27Z

Alerted Marshall Clow (LWG chair) to this change.

jensmaurer force-pushed the b5 branch from 3bf990e to 60cd62b Compare December 1, 2016 08:30

jensmaurer assigned zygoloid Dec 8, 2016

jensmaurer force-pushed the b5 branch from 60cd62b to 5652abf Compare December 14, 2016 18:37

zygoloid reviewed Dec 14, 2016

View reviewed changes

zygoloid approved these changes Dec 14, 2016

View reviewed changes

zygoloid merged commit f8904bd into cplusplus:master Dec 15, 2016

jensmaurer deleted the b5 branch December 15, 2016 10:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[limits] Integrate section [limits.numeric] into section [numeric.lim… #1159

[limits] Integrate section [limits.numeric] into section [numeric.lim… #1159

jensmaurer commented Nov 30, 2016

tkoeppe commented Nov 30, 2016

jwakely commented Nov 30, 2016

W-E-Brown commented Nov 30, 2016 via email

jensmaurer commented Nov 30, 2016 •

edited

tkoeppe commented Nov 30, 2016

tkoeppe commented Nov 30, 2016 •

edited

jensmaurer commented Dec 1, 2016

jensmaurer commented Dec 1, 2016

W-E-Brown commented Dec 1, 2016

jensmaurer commented Dec 14, 2016

zygoloid Dec 14, 2016

jensmaurer Dec 14, 2016 •

edited

zygoloid Dec 15, 2016

jensmaurer Dec 15, 2016

zygoloid left a comment

tkoeppe commented Dec 15, 2016

jensmaurer commented Dec 16, 2016

[limits] Integrate section [limits.numeric] into section [numeric.lim… #1159

[limits] Integrate section [limits.numeric] into section [numeric.lim… #1159

Conversation

jensmaurer commented Nov 30, 2016

tkoeppe commented Nov 30, 2016

jwakely commented Nov 30, 2016

W-E-Brown commented Nov 30, 2016 via email

jensmaurer commented Nov 30, 2016 • edited

tkoeppe commented Nov 30, 2016

tkoeppe commented Nov 30, 2016 • edited

jensmaurer commented Dec 1, 2016

jensmaurer commented Dec 1, 2016

W-E-Brown commented Dec 1, 2016

jensmaurer commented Dec 14, 2016

zygoloid Dec 14, 2016

Choose a reason for hiding this comment

jensmaurer Dec 14, 2016 • edited

Choose a reason for hiding this comment

zygoloid Dec 15, 2016

Choose a reason for hiding this comment

jensmaurer Dec 15, 2016

Choose a reason for hiding this comment

zygoloid left a comment

Choose a reason for hiding this comment

tkoeppe commented Dec 15, 2016

jensmaurer commented Dec 16, 2016

jensmaurer commented Nov 30, 2016 •

edited

tkoeppe commented Nov 30, 2016 •

edited

jensmaurer Dec 14, 2016 •

edited