Upcoming C++ standards meeting in Rapperswil, Switzerland

[Botond Ballo]

Hi everyone!

The next meeting of the C++ Standards Committee will be June 4-9 in
Rapperswil, Switzerland.

This is going to be a pivotal meeting, with go / no-go decisions
expected for several highly-anticipated C++20 features, including a
subset of Modules; Coroutines; Ranges; and "natural syntax" Concepts /
abbreviated function templates. A discussion of whether or not to
continue efforts to standardize 2D Graphics is also scheduled (see
arguments for [1] and against [2]). In addition, work will continue on
various Technical Specifications that are in flight (including,
notably, Reflection), and processing the large influx of new language
and library feature proposals.

If you're curious about the state of C++ standardization, I encourage
you to check out my blog posts where I summarize each meeting in
detail (most recent one here [3]), and the list of proposals being
considered by the committee (new ones since the last meeting can be
found here [4] and here [5]).

I will be attending this meeting, hanging out in the Evolution Working
Group (where new language features are discussed at the design level)
as usual. As always, if there's anything you'd like me to find out for
you at the meeting, or any feedback you'd like me to communicate,
please let me know!

Finally, I encourage you to reach out to me if you're thinking of
submitting a proposal to the committee. I'm always happy to help with
formulating and, if necessary, presenting a proposal.

Cheers,
Botond


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0988r0.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html
[3] https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-02
[5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#mailing2018-04

[Botond Ballo]

On Wed, May 23, 2018 at 4:05 PM, Jet Villegas <jvil...@mozilla.com> wrote:
> I'd rather see the committee focus on things like object lifetime management
> so we don't have to port everything to Rust just to get basic memory safety
> guarantees. How much leverage do we have to push on that?

I assume you mean "push for better object lifetime management" rather
than "push against the 2D graphics proposal".

The only current proposal that I'm aware of in this area is P0936R0
("Bind Returned/Initialized Objects to the Lifetime of Parameters")
[1]. This aims to extend C++'s lifetime extension rules to "see
through" suitably annotated function / constructor calls, such that
objects bound to parameters of such a function / constructor are kept
alive for the lifetime of the return value / constructed object (so
the annotation basically means "this function returns an object /
constructs an object that refers to its parameters, and therefore that
object should not outlive the parameters").

This is far from a "borrow checker" (indeed, it doesn't *catch*
lifetime errors, it *avoids* them by making certain objects live
longer), but it may be a step in the right direction. I would be
interested to hear some opinions on this proposal from C++ Mozilla
engineers: do we think a proposal like this would materially improve
our C++ usage from an ergonomic and/or safety perspective?

If we like this proposal, we can certainly advocate for it when it's
presented, and vote for it if it comes up for a vote. (Procedurally,
the proposal was submitted prior to the previous meeting, and was not
looked at during the previous meeting because the Evolution Working
Group has a backlog of proposals. It will, hopefully, be looked at
during this coming meeting.) I will also keep a close eye on the
discussion, and report back any counter-arguments / concerns so we can
discuss and potentially respond to them. (So far, the main concern
I've heard is that by things "just working" without explicit lifetime
management more often, we would be lulling C++ programmers into a
false sense of safety.)

Beyond that, we could consider authoring additional proposals in this
area. As this is a tricky area of the language, we may want to
consider prototyping any proposal (either as a pure library, or via
modifications to our clang plugin) prior to submitting it.

There is also work being done in this area outside the formal
standards process, in the form of the C++ Core Guidelines [2] (some of
which can be checked statically) and the accompanying Guideline
Support Library [3], and in the form of Microsoft's lifetime checker
[4], though that seems to be progressing very slowly, and even though
I ask for an update at every meeting, I haven't seen much of substance
there.

Cheers,
Botond

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0936r0.pdf
[2] https://github.com/isocpp/CppCoreGuidelines
[3] https://github.com/Microsoft/GSL
[4] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/

[Chris Peterson]

On 2018-05-23 1:35 PM, Botond Ballo wrote:
> There is also work being done in this area outside the formal
> standards process, in the form of the C++ Core Guidelines [2] (some of
> which can be checked statically) and the accompanying Guideline
> Support Library [3], and in the form of Microsoft's lifetime checker
> [4], though that seems to be progressing very slowly, and even though
> I ask for an update at every meeting, I haven't seen much of substance
> there.

Facebook's Infer static analysis tool is adding more deeper checks for
ownership lifetimes. They describe it as a "rough prototype of
Rust-style borrow checker for C++."

https://github.com/facebook/infer/releases/tag/v0.14.0

[Jet Villegas]

The New checker features look really promising. Yes, more of this stuff in
C++ is very welcome.

On Wed, May 23, 2018 at 1:53 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Jet Villegas]

The continued work on the 2D GFx API as a C++ standard is concerning. Since
we're sending a GFx engineer to the committee, and AFAIK we're not going to
use such an API to build our GFx stack, the arguments against continued
development seem very compelling:

-

there are no clear users or demand for this feature from the community,
-

there is higher impact work that a 2D drawing library depends on,
-

there is higher impact work in general, and
-

the committee does not have infinite time,

I'd rather see the committee focus on things like object lifetime
management so we don't have to port everything to Rust just to get basic
memory safety guarantees. How much leverage do we have to push on that?

Thanks,

--Jet

[Jet Villegas]

On Wed, May 23, 2018 at 1:35 PM, Botond Ballo <bba...@mozilla.com> wrote:

> On Wed, May 23, 2018 at 4:05 PM, Jet Villegas <jvil...@mozilla.com>
> wrote:

> > I'd rather see the committee focus on things like object lifetime
> management
> > so we don't have to port everything to Rust just to get basic memory
> safety
> > guarantees. How much leverage do we have to push on that?
>

> I assume you mean "push for better object lifetime management" rather
> than "push against the 2D graphics proposal".
>

Yes, but please remind folks that Firefox already works with Cairo 2D and
we've made our implementation available for all :-)

> The only current proposal that I'm aware of in this area is P0936R0
> ("Bind Returned/Initialized Objects to the Lifetime of Parameters")
> [1]. This aims to extend C++'s lifetime extension rules to "see
> through" suitably annotated function / constructor calls, such that
> objects bound to parameters of such a function / constructor are kept
> alive for the lifetime of the return value / constructed object (so
> the annotation basically means "this function returns an object /
> constructs an object that refers to its parameters, and therefore that
> object should not outlive the parameters").
>
>

That actually sounds like a good thing to have. We'll continue to push on
Rust but still good to tighten up existing C++ code over time.

[Botond Ballo]

My blog post about what happened at this meeting is now live:

https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/

Cheers,
Botond

[Eric Shepherd (Sheppy)]

Thanks for sharing that overview!

Although I can see why there's a lot of resistance to adding a graphics
library to the C++ standard, it seems to me like a good idea. Even though,
yes, there are going to be better and faster libraries out there, it's also
true that anyone looking to maximize performance is going to be bypassing
parts of the standard runtime anyway. Even text-based applications often
bypass the standard I/O library to do their output more directly to the
console (as I think back to my days of directly blasting characters into
the text screen's video memory). Math routines are often replaced with
custom libraries that do things faster, either using better algorithms,
making use of processor features not directly supported by the standard
library, or by making accuracy concessions when all you need are "good
enough" values.

A standard graphics library would serve to make it easier for new
programers to onboard, would be great for quick tools that graph the
results of a problem being solved, or even many simple or low-intensity
applications that simply don't need high-performance graphics.

I do think that parts of the proposal could be broken off into separate
components. The linear algebra stuff, along with geometry, could be split
out into a separate proposal, since these have uses beyond 2D graphics.
This would both help bring other capabilities to light sooner, but would
lighten up the graphics proposal as well.

> > [3] https://botondballo.wordpress.com/2018/03/28/trip-report-c-
> standards-meeting-in-jacksonville-march-2018/
> > [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-02
> > [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/#
> mailing2018-04
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability <https://freebusy.io/eshe...@mozilla.com>

[Jeff Gilbert]

I agree with the sentiment in the write-up, that ideally beginner 2d
graphics needs are better handled by improving library/packaging
support, not by importing (and speccing??) an ancient library. For
instance in JS, people are more likely to pull in a library (of many)
to help with graphing, despite the availability of a standard 2D
drawing API.