Standardization

Standardizing Variant: Difficult Decisions—Anthony Williams

Techincal discussion information while standardizing N4542.

Standardizing Variant: Difficult Decisions

by Anthony Williams

From the article:

One of the papers proposed for the next version of the C++ Standard is N4542: Variant: a type safe union (v4). As you might guess from the (v4) in the title, this paper has been discussed several times by the committee, and revised in the light of discussions.

Boost has had a variant type for a long time, so it only seems natural to standardize it. However, there are a couple of design decisions made for boost::variant which members of the committee were uncomfortable with, so the current paper has a couple of differences from boost::variant. The most notable of these is that boost::variant has a "never empty" guarantee, whereas N4542 proposes a variant that can be empty.

Trip Report: C++ Standards Meeting in Lenexa, May 2015—Jason Merrill, Red Hat

With a Core language perspective, with extensive notes about modules discussions:

Lenexa C++ Meeting Report (Core Language)

by Jason Merrill

From the report:

Red Hat sent four engineers to the spring C++ meeting this year, in Lenexa, Kansas, a suburb of Kansas City.  It was hosted by Perceptive Software, a division of Lexmark.  The meeting went very smoothly overall; while there were some disagreements they were pretty cordial...

Trip report: Spring ISO C++ meeting

(I'm writing my trip report now that all the post-meeting papers are available and linkable this week.)

The spring ISO C++ meeting was held on May 4-9 in Lenexa, KS, USA. Many thanks again to Lexmark for hosting us! There were 93 experts at this meeting, officially representing 5 nations. Last fall’s meeting (see trip report) saw a recent-record number of over 120 papers; for this meeting it was over 140 papers in the two pre-meeting mailings (February and April).

As usual, we met for six days, starting Monday morning and ending on Saturday afternoon, with a number of evening sessions to fill out the round-the-clock technical discussions.

There was particular interest in planning for C++17; this was the subject of the Monday evening sessions led by Bjarne Stroustrup based on this draft “Thoughts on C++17” paper published a week before the meeting... after Bjarne’s initial internal and more informal committee email leaked to Reddit. There’s nothing like having a forcing function to write up an actual paper!

For a detailed list of papers that were adopted at this meeting, see the post-meeting mailing that just went live for the papers marked “Adopted 2015-05.” Also, check out STL’s nice summary posted on Reddit, and the video “The future of C++[17] -- Updates from Lenexa” on Channel 9 with Gabriel Dos Reis and Artur Laksberg. [ETA: Also Botond Ballo's detailed trip report.]

TS Milestones: 3 Completed, 1 Sent For Comment Ballot

We finished three more Technical Specifications, incorporating their ballot comments and sending the final text to ISO for publication. These should all be formally published this summer: Transactional Memory TS (project editor: Michael Wong), Parallelism TS (project editor: Jared Hoberock), and the Library Fundamentals TS (project editor: Jeffrey Yasskin). All of them had only minor tweaks at this meeting.

In addition, we also sent the Concurrency TS out for its comment ballot (project editor: Artur Laksberg). We hope to address the comments at our fall meeting in Kona; if they can all be addressed in one meeting, the Concurrency TS would be completed this year, making four TSes published this year. I asked Artur for a summary and here’s what he wrote: “The Concurrency TS consists of three parts: First, it introduces improvements to std::future<T> to enable wait-free composition of asynchronous operations. It introduces the concepts of continuation (the “then” API) for chaining multiple futures as well join and choice operations, represented by, respectively, when_all and when_any APIs. Second, the TS introduces thread coordination mechanisms called latch, barrier and flex_barrier. These mechanisms allow one or more threads to block until an operation is completed. An individual latch is a single-use object: once the operation has been completed, it cannot be reused. A barrier is re-usable: once the operation has been completed, the threads can re-use the same barrier. Flex barriers allow additional behavior to be defined when an operation has completed. Finally, the TS introduces class templates atomic_shared_ptr<T> and atomic_weak_ptr<T>, which are useful for writing lock free code. Compared to the existing mechanisms, the new concepts offer superior performance and are less error-prone.” -- On a personal note, I’m especially happy with that last bit because that was my proposal. Not all proposals succeed even after several meetings’ worth of work, and it’s nice to see the atomic smart pointers make it into the TS.

Note that this means that in under 12 months we have published the C++14 International Standard and three Technical Specifications, and it’s possible that the Concurrency TS might become a fourth. That’s quite an achievement, and thanks very much to the above-mentioned editors and all of our hardworking project editors and contributors! You can always find a list of current projects and their editors at isocpp.org/std/status.

Other Major Projects Update

The Concepts TS just completed its comment ballot, and we considered most of the ballot comments in Lenexa. We’re going to have one more telecon to finish the comments, then decide whether it’s ready to publish this year. Of course, what matters to you as a developer is not just when the committee blesses a document, but when you can try out the feature in your compiler, so I’m happy to report that my understanding is that vendors are not waiting for the TS to be published to implement Concepts in real compilers: I’m told that GCC expects to adopt the Concepts reference implementation into its next release, GCC 6, which if GCC follows its usual schedule would likely be spring 2016; and I’m also told that one or two other major implementations are working on implementing Concepts.

Modules also made good progress where the redesign led by Gabriel Dos Reis got encouragement form the committee and I’m told agreement among the major compiler vendors, though there are still a few important but relatively minor details to decide. Among the major C++ compilers, I’m told there should be at least one shipping experimental implementation of the current modules design available by the end of this year.

Ranges made great progress. Eric Niebler has worked hard over the winter and spring and brought initial draft wording for applying ranges to the entire iterators and algorithms clauses of the standard – this is no small wording undertaking! A reference implementation tracking the proposal is available on GitHub. We hope to see, and possibly adopt, initial working draft wording for Ranges at our fall meeting.

Networking is well on the way to producing a TS working paper based on the Boost.ASIO library with detailed wording also expected for the next meeting where we might be able to start a working draft.

Coroutines (await, generators) made good progress at this meeting and might also have working draft wording in Kona for the primary proposal: Visual C++ is shipping a reference implementation in VS2015, and my understanding is that at least one other major compiler is looking at implementing it this summer for possible release around the end of the year. There are also complementary/alternative coroutines proposals still in flight, so this is an active and important space.

Finally, Reflection had an evening session to progress some papers, and many other papers and proposals made progress too.

CppCon, Games, and a new SG14: Game Development and Low-Latency

I want to end with one interesting thing that happened in Lenexa that involves the C++ community beyond just the traditional standards committee attendees.

This past September, the first-ever CppCon was held, and it’s surprising how influential it already is. Here is one example. There at CppCon, we had a Meet the Authors session – that’s not too unusual at this kind of conference, and you might even think it would likely be a “lightweight” or “fluffy” kind of session. Well, never mind that there were a dozen heavyweight authors on the panel, from Bjarne Stroustrup and Scott Meyers on down all on the same stage, but that hour of discussion had real influence. In particular, the topic of ISO C++ and game development came up from the audience, and Michael Wong volunteered to arrange and lead a session later in the CppCon week on that topic. (CppCon deliberately leaves room for this kind of flexibility to be able to respond to whatever will get the most benefit out of the face-to-face time we have at the event.)

That extra session was strongly attended. In that session and since, Mike has continued to be approached by a steady stream of game developers who are interested in contributing to C++ standardization. And in addition to game-specific developers, there also seems to be a strong overlap with other developers interested in low latency programming for reasons other than frame rates.

What does all this have to do with the spring ISO C++ meeting? In Lenexa, Mike Wong reported the above backstory. When I polled the ISO C++ committee members in the room, a couple of dozen said they would be interested in participating in such work – and that’s a very strong response for a single topic area.

So this discussion that started brewing at CppCon has had a real result: At the Lenexa meeting, I created a new Study Group 14 on Game Development and Low-Latency Computing, with Mike Wong graciously volunteering to serve as the initial SG14 chair.

The next question was, how do we engage with this community? To get started, based on the community’s feedback through Mike, we realized need to overcome two particular challenges:

  • Some of these experts have submitted proposals to ISO C++ before, but it was at a time when the committee was busy shutting down C++11 and it might have appeared that the committee wasn’t interested (though we are).
  • These developers remain interested in contributing to C++ standardization, but they’re busy with their own conference schedule and product deadlines (so we need to meet them where they are).

Together, we felt this means we should start by meeting the gamers (and other low-latency developers) where they already are – by having official SG14 meetings “out in the field” starting at CppCon this September because that’s where they already were to start this drive last year. Having “side meetings on particular topic areas” that are separate from full ISO C++ meetings is exactly what Study Groups are for.

Our intention is to have formal SG14 meetings in the coming months located where these developers are, in addition to our full ISO C++ meetings:

1. SG14 @ CppCon 2015 in September. Mike and I will convene a full-day formal SG14 meeting at CppCon itself, currently tentatively scheduled for Wednesday. In attendance will be a number of long-time ISO C++ committee members and leadership, including but not limited to Mike (SG14 chair, CEO of OpenMP, and chair of Canada’s C++ committee), Ville Voutilainen (WG21 Evolution Working Group chair, Finland C++ committee), and myself (WG21 convener). We hope this shows we’re serious about engaging on this topic area! The agenda will be to entertain proposal ideas, to find a core set of proposals that could have critical mass of support and volunteers that we can encourage work on, and to set a draft agenda for #2 below... (Note: CppCon registration is not required to attend just the SG14 meeting, but is required if you also want to attend some of the 100+ CppCon sessions.)

Following the outcome of meeting #1 at CppCon, there may also be topics raised at additional SG14 telecons, and/or the two intervening full ISO C++ meetings in October and February. Then...

2. SG14 @ GDC 2016 in March. Mike and I then plan to convene a 2-3 day SG14 meeting (or as much time as is needed), again likely on-site at GDC. As soon as this was suggested, ISO C++ committee member organizations in the room started approaching me to offer facilities support to host this meeting at the GDC site or within short walking distance.

Thanks again everyone in the game development and low-latency computing industries for the strong interest, and to the over 100 volunteers whose hard work behind the scenes made CppCon possible last year to enable this kind of interaction, and who are hard at work as we speak organizing it again this September! CppCon is clearly already getting to be “the place to be” for the whole C++ community – including the intersection of the standard and the industry. This is important, and great to see.

Next meeting

Our next full WG21 face-to-face meeting will be in October in Kona, HI, USA, hosted by Plum Hall and the Standard C++ Foundation.

In the meantime, over the summer we’ll be having several other smaller telecon meetings, including as noted above to try to finalize the Concepts TS and meet at CppCon for the new SG14.

Many thanks especially to the meeting hosts for graciously volunteering to organize these meetings!

2015-05 post-Lenexa mailing available

The 2015-05 mailing of new standards papers is now available.

NOTE: A number of these papers have already been publicized on this blog. This is the complete list including ones not previously publicized.

 

2015-05 post-Lenexa
N4483 Read-copy-update Paul E. McKenney 2015-04-14 2015-05 Concurrency
N4484 C++ Standard Library Active Issues List (Revision R93) Marshall Clow 2015-05-23 2015-05 Library
N4485 C++ Standard Library Defect Report List (Revision R93) Marshall Clow 2015-05-23 2015-05 Library
N4486 C++ Standard Library Closed Issues List (Revision R93) Marshall Clow 2015-05-23 2015-05 Library
N4487 Constexpr lambdas Faisal Vali, Ville Voutilainen 2015-04-28 2015-05 Evolution
N4488 Responses to PDTS comments on Transactional Memory, version 2 Jens Maurer 2015-05-07 2015-05 N4410 Concurrency
N4489 WG21 2015-04-24 Telecon Minutes Jonathan Wakely 2015-04-29 2015-05
N4490 WG21 2015-05 Lenexa Minutes Jonathan Wakely 2015-05-29 2015-05
N4491 PL22.16 2015-05 Lenexa Minutes (Draft) Jonathan Wakely 2015-05-30 2015-05
N4492 Thoughts about C++17 Bjarne Stroustrup 2015-05-15 2015-05
N4493 Thoughts on propagate_const Jonathan Coe missing
N4494 Multidimensional bounds, offset and array_view, revision 6 Lukasz Mendakiewicz, Herb Sutter 2015-05-01 2015-05 N4346 Library
N4495 Operator dot Mathias Gaunard, Dietmar Kühl 2015-05-22 2015-05 Evolution
N4496 WG21 2014-11 Urbana Minutes (revision 1) Jonathan Wakely 2015-05-28 2015-05
N4497 PL22.16 2014-11 Urbana Minutes (Final) Jonathan Wakely 2015-05-30 2015-05
N4498 Variadic lock_guard (Rev. 2) Mike Spertus 2015-05-04 2015-05 N4470 Concurrency
N4499 Draft wording for Coroutines (Revision 2) Gor Nishanov, Daveed Vandevoorde 2015-05-22 2015-05 N4403 Evolution
N4500 Withdrawn missing
N4501 Working Draft, Technical Specification for C++ Extensions for Concurrency Artur Laksberg 2015-05-08 2015-05 Concurrency Adopted 2015-05
N4502 Proposing Standard Library Support for the C++ Detection Idiom, V2 Walter E. Brown 2015-05-03 2015-05 N4436 Library Adopted 2015-05
N4503 Atomic View (V3) Carter Edwards missing
N4504 Atomic View - Floats Carter Edwards missing
N4505 Working Draft, Technical Specification for C++ Extensions for Parallelism Jared Hoberock 2015-05-05 2015-05 N4407 Concurrency Adopted 2015-05
N4506 Parallelism TS Editor's Report Jared Hoberock 2015-05-06 2015-05 Concurrency
N4507 Technical Specification for C++ Extensions for Parallelism Jared Hoberock 2015-05-05 2015-05
N4508 A proposal to add shared_mutex (untimed) (Revision 4) Gor Nishanov 2015-05-05 2015-05 N4241 Concurrency Adopted 2015-05
N4509 constexpr atomic::is_always_lock_free Olivier Giroux, JF Bastien, Jeff Snyder 2015-05-05 2015-05 Concurrency
N4510 Minimal incomplete type support for standard containers, revision 4 Zhihao Yuan 2015-05-05 2015-05 N4390 Library Adopted 2015-05
N4511 Adding [nothrow-]swappable traits, revision 1 Daniel Krügler 2015-05-22 2015-05 N4426 Library
N4512 Multidimensional bounds, offset and array_view, revision 7 _ukasz Mendakiewicz, Herb Sutter 2015-05-07 2015-05 Library
N4513 Working Draft Technical Specification for C++ Extensions for Transactional Memory Michael Wong 2015-05-08 2015-05 N4301 Concurrency Adopted 2015-05
N4514 Technical Specification for C++ Extensions for Transactional Memory Michael Wong 2015-05-08 2015-05
N4515 Editor's Report: Technical Specification for C++ Extensions for Transactional Memory Michael Wong 2015-05-22 2015-05 N4338 Concurrency
N4516 Variant: a type-safe union (v3) Axel Naumann 2015-05-06 2015-05 N4450 Library Evolution Revised N4542
N4517 Record of Response: National Body Comments ISO/IEC PDTS 19841 Barry Hedquist 2015-05-08 2015-05
N4518 Make exception specifications be part of the type system, version 2 Jens Maurer 2015-05-08 2015-05 N4320 Core Revised N4533
N4519 Source-Code Information Capture Robert Douglas 2015-05-08 2015-05 Library Adopted 2015-05
N4520 Light-weight EAS rev. 5 Torvald Riegel missing Evolution
N4521 Merge Fundamentals V1 into V2 Jeffrey Yaskin 2015-04-12 2015-05 N4479 Library Evolution Adopted 2015-05
N4522 std::atomic_object_fence(mo, T&&...) Olivier Giroux, JF Bastien 2015-05-21 2015-05 Concurrency
N4523 constexpr std::thread::hardware_{true,false}_sharing_size Olivier Giroux, JF Bastien 2015-05-21 2015-05 Concurrency
N4524 Respect vector::reserve(request) Relative to Reallocation Nevin Liber 2015-05-22 2015-05 Library Evolution
N4525 C++ Standard Library Issues Resolved Directly In Lenexa Marshall Clow 2015-05-08 2015-05 Library Adopted 2015-05
N4526 Towards improved support for games, graphics, real-time, low latency, embedded systems Michael Wong, Sean Middleditch, Nicolas Guillemot 2015-05-22 2015-05 SG14
N4527 Working Draft, Standard for Programming Language C++ Richard Smith 2015-05-22 2015-05 N4431
N4528 Editor's Report -- Working Draft, Standard for Programming Language C++ Richard Smith 2015-05-22 2015-05
N4529 Working Draft, C++ Extensions for Library Fundamentals, Version 2 Jeffrey Yaskin 2015-05-22 2015-05 N4481 Library Evolution
N4530 Editor's Report for the Library Fundamentals TS Jeffrey Yaskin 2015-05-22 2015-05 Library Evolution
N4531 std::rand replacement, revision 3 Zhihao Yuan 2015-05-08 2015-05 N4316 Library
N4532 Proposed wording for default comparisons Jens Maurer 2015-05-22 2015-05 Evolution
N4533 Make exception specifications be part of the type system, version 3 Jens Maurer 2015-05-20 2015-05 N4518 Core
N4534 Data-Invariant Functions (revision 3) Jens Maurer 2015-05-22 2015-05 N4314 Library Evolution
N4535 Feature-testing preprocessor predicates for C++17 Clark Nelson, Richard Smith 2015-05-06 2015-05 Feature Testing
N4536 An algorithm to "clamp" a value between a pair of boundary values Martin Moene, Niels Dekker 2015-05-17 2015-05 Library Evolution
N4537 Adding Symmetry Between shared_ptr and weak_ptr Arthur O'Dwyer 2015-05-19 2015-05 Library
N4538 Technical Specification for C++ Extensions for Concurrency Artur Laksberg 2015-05-20 2015-05
N4539 Evolution Active Issues List (Revision R12) Ville Voutilainen 2015-05-22 2015-05 Evolution
N4540 Evolution Completed Issues List (Revision R12) Ville Voutilainen 2015-05-22 2015-05 Evolution
N4541 Evolution Closed Issues List (Revision R12) Ville Voutilainen 2015-05-22 2015-05 Evolution
N4542 Variant: a type-safe union (v4). Axel Naumann 2015-05-24 2015-05 N4516 Library Evolution
N4543 A polymorphic wrapper for all Callable objects David Krauss 2015-05-26 2015-05 Library Evolution
N4544 October 2015 WG21 Meeting (Kona) Thomas Plum 2015-05-26 2015-05

GoingNative 38: The future of C++[17] - Updates from Lenexa—Gabriel Ha

A nice recapitulative video of what C++17 could be:

GoingNative 38: The future of C++[17] - Updates from Lenexa

by Gabriel Ha

From the video:

A few weeks ago, the ISO C++ Committee met in Lenexa, Kansas to hash out the future of the C++ language, specifically for C++17. We're honored to speak to two (previously featured) Microsoft delegates to the committee -- Gabriel "Gaby" Dos Reis and Artur Laksberg -- who took the time to give us a very nice overview of the major things that went down at the meeting!

Announcing a financial assistance policy for ISO C++ meetings

Most of the following announcement will not immediately affect those who are not C++ standards committee members, but I hope everyone reading this blog who uses and relies on C++ will benefit from this new program.

 

I’m pleased to share that today at the ISO C++ meeting in Lenexa, Kansas, USA, the Standard C++ Foundation launched a new financial assistance policy intended to facilitate the work of WG21. You can find the policy here.

Thank you!

Before I mention details, let me thank two important groups without whose support this would not be possible:

  • Thank you to the members of the Standard C++ Foundation whose logos you see at right. Their financial investment in the Foundation has provided the core funding to support the Foundation’s work since its creation in November 2012.
  • Thank you to you, if you’re one of the hundreds who attended CppCon last September and/or one of the scores of volunteers who organized CppCon as a community C++ festival. The primary goal of CppCon was to deliver important information to the community, and so we kept ticket prices low to encourage attendance, we invested in recording all sessions to make them freely available to everyone... and thanks to the strong attendance response and all the volunteering help we got, we still managed to run at a modest profit that we can use both to run CppCon again (registration opens soon, watch this space!) and to invest back into the C++ community including through this new policy.

Overview

Remember that the Foundation is not the committee, even though many people and companies participate in both. Rather, the Foundation exists to support the community and the work of the committee while leaving standardization strictly under the C++ committee leadership’s direction. For that reason, this policy leaves it up to the C++ committee leadership as to how the financial support should best be applied. Also, please note that this policy is experimental and subject to revision or withdrawal, but we hope it will be successful in facilitating the work of the committee as we develop the TSes, C++17, and beyond.

The basic idea is that the Foundation will set aside a chunk of money for each meeting, that the convener and main subgroup chairs can draw on to facilitate WG21 work, notably in three areas:

  1. Meeting hosting, when not enough financial support is available.
  2. Travel to a meeting, for authors of important proposals who are not employed by a company and not able to fund it on their own.
  3. Further development of proposals, again when the authors are not employed by a company and not able to self-fund the work fully.

Note that both #2 and #3 are intended to directly help and foster community involvement beyond the big commercial corporations and academic/research institutions.

Recall: For much of the history of the C++ committee, we have had key participants who have made an enormous difference to C++ who have not been funded by a company, university, research lab, or other organization. Today, that hasn't changed: We continue to have some of our major proposals, including at least three large proposed libraries including Ranges (range-based STL using concepts), Networking (based on Boost.ASIO), and 2D Graphics (based on Cairo), that rely partly or entirely on the efforts of such individual world-class experts, and that have been developed to their current state by those experts’ unpaid volunteer efforts.

The committee has expressed strong interest in pursuing all of the three proposals I've just named, as well as others. However, nothing gets done unless someone can contribute sustained heavy work -- and because these key efforts are not funded by companies, some of these efforts likely cannot continue, and cannot be completed, without at least some assistance of the financial variety. We hope that the Foundation can help by starting to offer tactical travel assistance and grant funding for some of the costs of some of these kinds of contributors, so that we can help foster the work that the committee has declared an interest in, but that cannot progress without requiring some level of actual financial development assistance that would not happen if we relied on companies and other institutions alone.

Why a policy?

Since the last November’s standards meeting in particular, the Foundation directors have been working on putting together this policy because the Foundation had already become involved in supporting all three of these categories of standards-related work, but it has been in ad-hoc and on-demand ways as situations have arisen.

For example, even before there was a policy, the Foundation funded work from which the standardization effort is already benefiting at this week's meeting: Without the first grant issued as an initial one-off grant over the winter even before this regular policy became official, we would not now have a 170-page document before us containing near-complete working draft text for applying concepts and ranges to the entire STL iterators and algorithms libraries, along with an open source reference implementation on GitHub – and we do have that and are considering it at this week’s standards meeting.

Since this has worked very well in the form of ad-hoc one-off support, the Foundation directors decided it was time to establish a structure to formalize and regularize this support, and test how well it works more broadly.

So now that we have a policy, what’s different? The answer is, not too much -- the Foundation still wants to support those same things, and this policy mainly gives a regular and consistent structure for doing that. One major difference is that going forward it will be, not just the Foundation’s CEO and directors, but the committee leadership -- the convener and the four main subgroup chairs -- who will decide and approve where the support should be allocated. The Foundation directors will set a budget of what we can contribute toward each meeting, and the committee leadership will decide how they want to use it to promote the work of that meeting. (Note that there is overlap between the Foundation directors and the WG21 leadership, and some of us wear two hats, but the policy is written to distinguish those roles and designed for the long term as the people in particular roles evolve over time.)

Again, this is experimental and subject to review based on how it goes. As we try this out together with the committee subgroup chairs between now and our next meeting in October, we’ll get a better feel together for how it will all work in practice.

Finally, thank you again

Thank you again to the Standard C++ Foundation members at right who directly financially support the work of the Foundation including this initiative.

Thank you again to the CppCon attendees, and to the CppCon volunteers who contribute so much to the running of that conference to disseminate information and support the C++ community, because your support for CppCon feeds back into enabling things like this initiative.

Thank you again to the C++ committee members and leadership who work hard year after year to bring us modern Standard C++ at high quality.

Thank you all, dear readers, for all you do for Standard C++. The Foundation is glad to be able to try to provide some financial support for the good work of C++ standardization in key areas to promote the development of our Technical Specifications, C++17, and beyond, and we look forward with intense interest to see what future results these and other efforts may bring.

Herb

N4494: Multidimensional bounds, offset and array_view, rev. 6—Ɓukasz Mendakiewicz, Herb Sutter

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4494

Date: 2015-05-01

Multidimensional bounds, offset and array_view, revision 6

by Łukasz Mendakiewicz and Herb Sutter

Excerpt:

Revision 6 (N4494) incorporates the changes requested by LWG in Cologne meeting, marked as deletions and insertions.

The following suggestions were implemented fully:

  1. Rephrased coord.general avoid references to mathematical entites.
  2. Renamed index to offset.
  3. Changed int Rank template parameter to size_t Rank throughout the document.
  4. Made offset, bounds and bounds_iterator binary operators (apart from @= forms) free functions.
  5. Replaced term "component" with "element" when referring to the individual constituents of offset or bounds.
  6. In coord.bounds.require replaced prose with an equivalent mathematical expression.
  7. In coord.bounds.iterator and coord.bounds.iterator.require removed the requirement on bounds_iterator to represent a random access iterator, replacing with "as-if" phrasing.
  8. In the description of bounds_iterator& operator++() replaced the code snippet with equivalent prose.
  9. In views.general changed the font back to non-monospace.
  10. Removed views.require, duplicating it as arrayview.require and stridedarrayview.require.
  11. Removed redundant assignment operators on array_view and strided_array_view.
  12. Employed "exposition only" data members is the descriptions of array_view and strided_array_view semantics.
  13. Rephrased the first paragraph in arrayview.cons to avoid ambiguity in binding of the token "type".
  14. In constexpr array_view(Viewable&& vw) rephrased the third bullet point.
The following suggestion was implemented partially:
  1. Instead of the array_view(ArrayType& arr) constructor being completely removed, it has been constrained to 1-D case as the Committee indicated that such case does not exhibit the undefined behavior. We believe that the request to remove it completely was a misstatment.

The following suggestion was not implemented:

  1. The semantics of the proposed types were not extended to allow rank-0 cases. We feel that we lack sufficient practical experience in using such cases and we are afraid of some contention points when it comes to defining their detailed semantics. We observe that such an extension can be introduced in future without conflicting with the proposal in the current form.