- Good evening.
Welcome to Grill the Committee.
This is our opportunity
to fire our questions at
a representative sample
of the standards committee
and I don't mean this in the sense that
any of them are truly empowered
to speak for the committee.
I think they're speaking
for themselves here
but this is an opportunity for us to learn
how the committee thinks about things
by looking at some of the
people who are influential
and have been on the committee
a significant amount of time
and, what?
So I'm gonna allow you guys,
I want you to introduce yourself,
but I want you to talk about both
what your formal role on the committee is
and also what you feel
like you, personally,
are trying to accomplish on the committee.
Does that make sense?
- I'm Titus Winters.
I'm the chair for the Library
Evolution Working Group
which is the, it's the sub-committee room
that is responsible for API
design for the standard library.
So what were the questions exactly?
What is my, that's my formal role.
- Yeah, yeah, so the
other thing is what is it
you personally are trying to
accomplish on the committee?
- So my two biggest
goals for the committee
are to minimize the number
of missteps that we make
in library design, it's
really, really expensive
and frustrating and annoying
when my very large code base
has to do something different
than what the standard does.
And we will if we have
to, but it's not pleasant
and I don't like to do
it, so I would much rather
get it early, so I sit in
library evolution constantly,
even before I was the
chair, to try to like catch
API design problems and
then the second thing
that I do at the committee level
is try to get the committee
to grant itself the right to fix mistakes,
(audience laughs)
which is a deeply
fraught process.
(audience laughs)
Many of the things that I worry about
are whether the committee is prioritizing
every piece of code that
has ever been written
or every piece of code
that ever will be written.
And that is not a small question
and one of the things
that makes me very happy
about there actually being
a Grill the Committee,
is hey this is literally
the biggest sample
of the C++ community that we're gonna get,
so tell us how you feel yo.
(audience laughs)
- I'm Herb Sutter, I'm currently
the chair of the committee
and the sys administrative
role, I convene meetings
and including extra ones
like we just actually
this is day five for some
people who have been in
committee meetings like I
think most of the people
on this stage, for the last four days,
yes that includes the weekend,
those are calendar days
and because we were all
here so let's work some more
on modules and executors,
so thank you to all those who did that.
Personally apart from my
administrative role where I
run the committee, but
I do not speak for it,
personally I have goals
and I still don't speak
for the committee, but
my personal goals involve
evolving C++ in a way that
will simplify C++ code
and yes that means adding
things to the language
that makes the language
bigger, but code simpler,
and that overlaps well
with the kind of goals
that Titus had including
how can we eventually
fix more of our mistakes,
so that's something
I'm working on as a multi-year project.
- Hi, I am Olivier Giroux.
Or you can also call me Oliver.
I am the chair of the study group
for concurrency and parallelism,
it's a fairly big group,
I think only the evolution
working group ends up
meeting in larger rooms, my
personal goal for the group
you know I only had this
much time to think about it,
actually I have two so
there's a lot of activity
in concurrency and
parallelism, it's definitely
where all the exciting new platforms are
from all of the big businesses,
so there's a lot of pressure
coming into SG1 from various corporations
to extend the reach of C++
beyond where it's been before.
So I have two goals for personally.
I want the SG1 room to
work a bit like a team.
We are formerly not a
team on the committee.
We're a large herd of cats,
but SG1 used to, people used to
claw at each other a little bit more
and that has changed, we
now work more together
and I want to reinforce
that, so that's one thing.
And then the second thing
is I sort of have a bar
where I want conscientious designs.
It's really easy to make parallel
and concurrent constructs
that are just a way to lose more fingers
and I really want to encourage
the conscientious design
approach where you can
use things correctly
probably the first time.
- Oh, you have an
independent mind, cheers.
(audience laughs) So Bjarne
Stroustrup, my only former
role in the committee is to
be on the direction group
and I am this year's chair of that group
because of a random number generator,
which may or may not have played fair.
(audience laughs) Howard wrote
it and I didn't verify it,
but anyway, in that group
we try to set a direction
for C++, in particular, it's
not the directions group.
We're trying actually to have a direction
and we are considering
what that direction is,
what the rate of change
can be, where the emphasis
on desirable improvements should be.
My personal aim is to
get C++ more coherent,
have a more solid
foundation for everything.
Throughout the keynote you'll see me
in the domain of generic
programming, but that's not
by any means the only
place where we can do
with a better foundation and
basically trying to popularize
a couple of slogans like
keep simple things simple
and remember the Vasa.
- My name is Marshall Clow.
I'm the chairman of the
library working group.
We are responsible for the
wording for the back two thirds
of the standards of say
from page 500 to 1,500.
The library working group is
one of the smaller working groups.
It tends to be dominated by a group of
intensely conservative people.
These are the people who have
standard library implementations,
but we so try to balance this like
oh you're going to break my implementation
with oh we need to keep moving forward.
I am one of the people with
implementations by the way.
Anyway, so my personal goal is
to keep things moving forward
without pissing off the
implementers too bad,
because I don't want to piss off myself
and as a side benefit, if I
can break Titus's code base
on a regular basis, that's all good.
(audience laughs)
- Come at me bro.
(audience laughs)
- No seriously, we try
really hard not to break
other people's code and
we go to a lot of effort
in people's implementations
not to break code
and in the LWG group, as Titus has said,
it's like huh, oh we can't do that because
it's going to break existing
code that does this.
And sometimes the answer is
oh well that's just dumb.
That's dumb code, we
should break that code
and we don't always agree
on that, but anyway.
But anyway, so I agree
with Titus in general
that we need to figure out when it is okay
to break people's code
and the answer right now
is almost never and I
think we should move it up
to very, very rarely, but still.
That's all I got to say.
- My name is Howard Hinnant.
I have a couple of roles on the committee.
One of them is to represent
my employer, Ripple,
who has sent me to these meetings
and I'm very grateful for that.
I'm also a member of the directions group
and am in charge of randomly
choosing the chairman,
which will never be me.
(audience laughs)
Random chance of course,
let's see I've been on the
committee for a couple of decades
and I've got my finger
prints on various things
like move semantics and chrono and--
- Calendars.
- Calendars coming up
in C++ 20, there'll be a lightning talk
on that tomorrow night,
come see that.
- You're gonna time it
using the library?
- Marketing.
- I will time it using the library
and let's see I guess that's
about all that keeps me busy.
Here you go Ville.
- All right, my name is Ville Voutilainen.
I chair evolution, so that
Bjarne and Olivier needs to.
So I herd the evolutionary cats
and occasionally I help
herd the cat in general.
As I call it, I tend to the kindergarten.
(audience laughs)
So as far as my personal goals go,
we have a bunch of major
features in the pipeline,
concepts, contracts and
well likely modules as well,
so what I'm trying to
do is surreptitiously
guide the group to no
small extent via my papers
to actually finish concepts and contracts
and then as far as modules go,
I heavy handedly tell the proposal authors
to finish that particular job.
- Thank you I just want to
I don't know if you guys
noticed, do you know what
professional cat herders
say after a bad day?
- Ouch.
(Jon laughs)
- They say, it could have been worse.
They could have been speakers.
All right, if you have any questions,
that's what the session is for.
So come on up to the mic.
(audience laughs)
(audience claps)
- Okay.
- Is it on, is it on?
- Obviously.
- Is it on, okay.
- Thank you.
- So hello, so actually
I do have a question
and it's semi-related to modules.
Why can we not make a
translation unit a file?
- To get to the other side?
- No.
(audience laughs)
- So we could, but why would
that be the best choice
that we can make as
opposed to having some sort
of freedom about your code layout?
- You can still have
freedom of code layout
if you have directories and files.
It doesn't say that they have
to be in a specific location.
But it does let you say well now we know
how to find a module,
interface or implementation.
- Committee's welcoming proposals.
- I can write something in a week.
- I think part of the answer
is what should be in that file?
Because of course they are files,
it's just not C++ source code files
and the reason for that
is that it takes forever
to pass a source code into something
that can be used as a module.
- I just want to see if
anyone else has anything else
to say, like I'm--
- Okay.
- Okay.
- All right, thank you.
- I have one more question,
so I'm going to be
staying in the back now.
- Okay.
- I love unique pointer, I like variance,
but I get tired of writing
things like stood variance,
stood unique pointer A,
stood unique pointer B,
some languages with less history manage
to get this right earlier,
obviously C has more history,
but can we get some direction
on getting those things
to be nicer to write?
- That is definitely, it is bananas hard,
but if I had absolute power
(audience laughs)
to deploy tooling that I
know absolutely could exist
it would take 10 years
or so for the standard
to reclaim the global name space
and then we could move
all of those things back.
I don't know if that is actually worth it,
because that is extremely
expensive, very breaking change,
but then you actually would
have the nice property
of everything that is
standard, including int,
lives in the global name space,
all of the things that are most common
have the shortest names which is what you
want in the language.
- I'm not even afraid
of the stood in front
and I absolutely agree
that it's so much easier to
put things through library
than through syntax because joining syntax
that's a big thing, still new was so nice,
you could just write new.
- Well but this is the language
that gets the defaults wrong
by default, which is the wrong default.
(audience laughs)
- I know!
- I mean
(audience laughs)
like yeah it's a matter
of legacy and you know
on the upside we'll give
you better performance
than anyone else.
(audience laughs)
- Just to understand your question,
I think you partly answered it.
Are you asking for thing, it's
not the STD you care about,
you'd like things like well what if new
returned a unique pointer,
is that what your asking?
- Oh, that would be great if
you could do that, please.
(audience laughs) I mean--
- I have no answer,
I'm just trying to understand the question
and what you would like it to be,
or I'm curious if you're
alone, how many here
if you could rewrite
history would love to be
in an alternate reality C++ where new just
returned unique pointer by default?
Cool, I did not know
if one head would go up
or lots and I'm surprised with how many.
(audience laughs)
- Thank you.
- We have an alternate
spelling of new that does that,
but it's longer.
(audience laughs)
I think you know yeah.
- I know I know I was yeah.
- Sorry for those that didn't hear it,
I said we have an
alternate spelling of new
that does that, it's spelled
M-A-K-E underscore U-N-I-Q-U-E
but it's much longer,
but I'm guessing that
every single one of you has an editor
that has macros and you could type MU.
(audience laughs)
- [Audience Member] Give me the
legacy code, leave it to me.
(audience laughs)
- Let the record show we
got 18 minutes into this
before somebody said the M word.
- I thought that was going
to be let the record show
our show got voted off the stage.
(audience laughs)
- But I will get star to
mean unique pointer as well?
- No.
- No, sorry.
- We have to remember that
we've got a few billion
lines of code out there and
we have no control over it
and we have a few million programmers
out there we can't retrain them.
It's a big problem and
it sometimes I think
I'm even more conservative than say Titus.
I just want people to
use modules and concepts
and things like that consistently,
but you have to talk people into doing it.
Making things simple and simpler is hard.
I like the fact that we
now no longer have to say
vector of ints, we can deduce the int.
No longer has to say sort
of something dot begin
comma something dot end,
we can say something thanks
to the rangers' proposal
and such, we can simplify,
but there's a sort of
probably a maximum rate of
change that we can sustain
and people always want new things.
They always want simple things
and above all don't break my code.
- Okay thank you.
- Thank you.
Sometimes people are afraid
actually to combine them.
- So one thing I end up doing
in every company I work at
is re-implement reflection,
so one of the things
I wanted to ask the committee
is I know there's proposals
out there for reflection,
but I just wanted to know
what the status on getting
reflection into C++ was.
- So we have a technical specification.
We expect to go in a
direction that's different
from that technical specification.
(audience laughs)
Hold on.
(audience laughs)
So we expect that the
implementation of that TS
will provide us the underlying plumbing
that will be used for the
actual kind of reflection
that we want to do,
so once I'm done with
concepts, modules and contracts
and we actually ship C++ 20,
reflection is going to be
a suggested major feature goal for C++ 23.
Whether we'll get there
within the 23 timeframe
remains to be seen, but I'm going to twist
a couple of thumbs so that we make
the best effort that we can.
- Well at the end of the
year if you guys need help
on reflection, I'd be
willing to help at the end
of the year, so I guess I'll contact you
and see if I can't help you out with that.
- I have a slightly off topic comment.
I see a lot of people standing
in the aisles in the back.
I see a lot of empty seats
here, here, there, there.
Come on in and sit down,
don't look like you're going
to bolt the first time
I say something wrong.
- And thank you guys very much.
- They would already be gone Marshall if--
(audience laughs)
- Welcome back Izzy.
- Hello again, so I was
going to ask about the restrict qualifier,
but I decided to change my
mind the last minute or so,
so Arthur Eduardo, I don't
know if Arthur is here,
there he is actually,
so Arthur is writing this
trivially relocatable paper.
- It's on my badge.
- Cool.
- The paper fits on your badge?
- So the question I have
is how hard would it be
for us to in addition to
having non-destructive moves
as we go currently do
with the way things are
to make relocation our
destructive move effectively?
To you know basically have what Rust has,
where they just do a move
and then they don't have
to worry about anything
because the old value
got I think the phrase you use
is the compiler drops it on the floor
and I would really appreciate
that, because it's nice.
- So I think destructive
move would be a distinct
advantage to have a good feature.
I don't think it would replace
our non-destructive move
at all-
- Well I didn't say it--
- But I think it would
complement it very nicely,
because there's several
places where it would be
very useful, for example
with the vector buffer
reallocation, it's a
prime example of where
destructive move is just a perfect fit.
So any time you've got
something that's on the heat
that you need to move
from one place to another,
where the compiler is
going to automatically
call a destructor on you,
I think that'd be great
and maybe Arthur can add to that.
- The only thing that
I would here is that--
- Can you speak up to the mic please?
- Yeah, get up to the mic.
- I do have a paper.
- Once more.
- I do have a paper, it will
be in the San Diego mailing.
I won't be at San Diego,
someone will be shepherding it
and I forget if I have someone or not,
but I just want to point out
the paper's not published yet
so someone on stage is
going to say the paper
is not even published yet
and that's completely true.
- Actually I was going
to say, there's a paper
that's making its way through,
there's active interest
in the feature, but it's
really early to talk about it.
So for all the things that were mentioned,
those are all great use cases.
You can imagine other cases where somebody
might want to move an
object's address in memory,
which in general you
can't do to a C++ object
without potentially
confusing it and the system,
but if you know a type's relocatable,
you could say have a
compacting memory arena.
There's lot of things that it enables.
So there's definite interest there,
but it's early days for the proposal.
It's going to take some time to mature.
- Okay, and Arthur I'm
going to be at San Diego,
so someone will be there.
- Yes, we do have interest
in having this facility.
We have tried having it before
and the earlier proposals
didn't quite solve
the concerns of how it will interact
with certain expectations
of object lifetime,
so it's a non-trivial problem.
I would be more than
happy to see a proposal
that actually works so that we don't
run into those problems.
- Yeah, I was just going to comment
that for most proposals 90% of the work
is integration with the
rest of the language
and the library and such, and quite often,
people has a great idea,
even if it's great,
underestimate that
amount of work enormously
and quite often it's a proposal
that ends doing most of it.
And the other thing is
that the last thing we need
just now is bright new
ideas before we manage
to do the feature freeze for 20,
so we're a little bit late on it.
- You're really not going
to like San Diego then.
(audience laughs)
- I just want to say I know
there's at least one person
at CPP Con who has written
almost exactly this paper before,
I suspect it's a person on the stage
who's written almost
exactly this paper before.
It's not a new idea and it's not an idea
that hasn't been done before.
- Okay.
- I think I'm done actually
so I'm just going to.
- Thank you.
- Hello, let me just say first,
this is quite intimidating.
(audience laughs)
So I've never heard of destructive move,
but I feel like this question's
actually a little bit related.
In my company, I've noticed
that people just don't
use move very often,
because you have to use it,
you have to say I want to move,
so you can move without
realizing that you can't
and you cannot move without
realizing that you can
and I'm wondering if
there's any plan to enable
I don't know a smarter
compiler that would move
when you don't explicitly say to move,
I mean I know it breaks
a lot of the semantics
of destructors when
they run and everything,
but I feel like for most
types it doesn't matter?
- So one half of that you said you can
move when you can't and
I assume that you mean,
you call stood move and it doesn't matter?
- Yeah well the two scenarios
are you use after move
and you don't use after you copy,
which one has to be a
copy, one has to be a move.
- Okay, now that stops being
a library question at all
and that becomes a language
question, so I'm done.
(audience laughs)
- I'll just add that
some of the lifetime-related
work which I talked about
a few years ago at CPP
Con that I'll be talking
more about it on Thursday,
part of it applies
to detecting use after move,
but it's not the only thing.
There's actually several static analyzers
who are actively doing work this year
and starting to ship in experimental form
to detect use after move.
To me the most interesting
thing that I've encountered
as the folks I'm working
with have been testing
those against some earlier real world code
and again I stress all of this is early,
none of this happens in a month or a year,
but you learn things when your first start
using it in real world code.
But I meant to tell you this
Bjarne and I'll tell you now.
(audience laughs)
So it turns out that first yes in fact
you do detect some great
use after move bugs
and you can make great
slides and show that
hey look you used this after move,
you shouldn't use this object again
unless you call it on a function
with no pre-conditions blah blah blah.
The other thing you find
which I should have realized,
but didn't, because I'm
dumb and didn't have
the foresight to see it is
you start flagging places
where people wrote move unnecessarily,
which you'll love, it appears
in the LLVM code base.
(audience laughs)
- I didn't know that, but
my first recommendation
is don't use that move,
second recommendation,
in emergencies you might
very rarely use stood move.
It moves implicitly very nicely,
and it's very rare that
you really, really need it.
- So we do have some active work on
removing some restrictions
on whether you need to use
move on a return, as far
as needing to use move
and passing something into a function,
yeah I do know how Rust works.
It's non-obvious to me
that that way is superior.
I would need to have evidence
that the breakage of existing assumptions
on the validity of the local variable
are really worth changing those
semantics of the language.
- I see.
- Yeah and if you go back
to my talk from today, at a library level,
one of the things that
I very specifically said
was copy and move or no reload set,
if a type doesn't move effectively,
that's the author's bug, if you don't move
when it is relevant and might
be useful, that is your bug
and I don't believe that you should be
specifically be limiting
yourself to only calling
stood move when there
actually is a move constructor
for a type, because
you might know that the
type is currently expensive
and that the author
just hasn't gotten around to writing
a move constructor for it,
like if it's a heavyweight type,
you should probably stood move it
to be future compatible with
that oncoming optimization.
That's my logic.
- Yeah, I figured you
might say something about
the overload set, because
yeah if you can make
two overloads and one takes a construct
and one takes a ref
ref, but I find at least
the code that me and my coworkers write,
we don't want to do that,
we just want to make the
value one that you can
optionally move into
it and I just want that
to automatically move when it can.
If you don't use it again,
then you can move it
and the code reviewer might
say oh you should have
used stood move here,
so I want the compiler
to be the code reviewer and it to say
you can use stood move here.
- But the compiler can only do that
if it can tell that your
destructor for that type
does not ever matter, right?
- Yeah.
- And because this is a
language where destructors
are so heavily used and
so deeply important,
that's asking for a
non-trivial amount of magic.
- Yes, and I want the magic please.
(audience laughs)
(audience claps)
- Let's come back to the
committee with a solution
to the holding problem.
- Okay, will do.
- There might be simpler
solutions for simpler cases,
but a lot of the interesting
ones, you really end up
with the impossibility there.
- We're starting to get a bit
of a line here, so I'm going
to every once in a while
budge us to move on.
- All right, thank you
very much.
- Herb, your static analysis
thing doesn't solve his problem does it?
You can detect use after move,
but you can't detect like
no use after move, is that possible?
No no?
- There's flip sides to it.
First of all, it doesn't detect
every use after move at all
because you can't find them all.
When you do that you detect
rote stood move and shouldn't--
- [Arthur] Transfer false negatives
to false positives yeah.
- What I believe the
questioner was asking
for is on every simple
control flow path through
if the last use of a value
is not a move, implicitly make it a move,
something like that,
I'd love to see a paper.
It's been suggested, I saw
committee e-mail reflector
messages on that just this
summer, but it takes a paper.
- Ville I mentioned a couple
of papers coming to EWG
on return statements in particular,
come to my talk tomorrow for that,
but my question was much more trivial,
I almost asked it to Bjarne after his talk
and I was like Herb stick
around, this is for you too,
and the question is giraffe
case in Bjarne's presentation
and in your paper on
concept syntax, you have
capital B value underscore lower case type
and you know capital F
forward lower case interator.
What's--
- I hate that
and I do it because I'm a nice guy.
- Where did that come from
and why do you keep doing it?
Who started that?
Is that person on the stage?
- I still strongly prefer underscores
and I hate those capital
letters in the middle of words
and somewhere in the depths of time
we started somebody started
to use that notation
for concepts and it has just stuck.
If someone wants to rename
them they can make a proposal.
I would probably support it if I thought
there was little enough use.
If you look at my old
papers, like from last year,
I tend to use the underscores.
There was an idea that it would be nicer
if concepts were named different
from other identifiers.
It's a bright idea people
get for every new thing.
They have to stand out and be loud.
I believed that too five
years ago and I was wrong.
Having things stand out
just because they are new
means that soon it will
not be new anymore.
The question is whether this mistake
can be changed at this stage.
If you write a paper,
it will be considered.
- Let me just say the reason
I just went along with it,
even though I found it not
very palatable is because
it doesn't really matter.
It's great to get agitated
about a battered water cooler
and life's too short for that.
It works, it compiles, I
want to solve more problems.
That's not a problem I'm
interested in spending cycles on.
- And as the resident we
haven't actually committed
to supporting any of that,
all of the usage of concept
is not in any published standard.
We can change all of the names right now
and I will argue deeply
against anyone that says
oh, there's users of that,
I'm like I don't care.
You all are using it out of
experimental, you don't count.
- I'm a user officially and I care--
- Not of a draft, not of a standard--
- That it is changed.
- Oh (laughs) oh so fine.
- All right, thank you.
- I will merely point out
in all the concepts in
the rangers' proposal
are all camel-cased, no underscores.
(audience claps)
I offer no opinion, just point it out.
First letter cap camel-case--
- PASCAL.
- PASCAL-cased.
- Double case is lower letter.
(audience laughs)
- I don't design this stuff.
- All of the camels I've
seen are high at the front.
(audience laughs)
- How many hills
can you die on?
- Did you have a question
Gaspar?
- Gaspar save us from this.
- True, okay Gaspar you're up.
- Right, so as a person who
is seeing a feature freeze
for a standard for the first time,
because I haven't been
an author for too long,
could you please explain what that means?
- About a year before we
ship, we feature freeze,
we send out what's called
a committee draft where
you want the features frozen,
because that's your ballot
comment where you're going to
get your ballot for comments
where the national body
some of whom haven't looked
at your work till you say
you're ready to review it
are going to look at it and so you want
all the features to be there.
It's considered impolite
to add a feature after that
in the final ballot, somebody may stand up
on their hind legs and say hey what?
So we have a feature
freeze and it also gives us
about a year to do bug
fixes and the long tail
of issues that got deferred
that we want to ship,
so we currently want to
aim for the first or second
meeting next year to
feature freeze for C++ 20.
That means that there's
a land rush right now
to get major proposals in,
because you do not want
to wait the committee
will not let you wait
till the last meeting to do that,
so all the big rocks are now
people are angsting to get in
for San Diego and possibly Kona.
So we're in that phase of the cycle
where there's lots of work right now
and usually it also means that more people
are attending committee meetings.
We're at about double what
we were five years ago,
so we've been regularly
getting about 140 people
at each meeting for the
last couple of meetings.
And that's typical, the
bump is higher than before.
The number is higher, but the bump itself,
the shape is typical for this
phase in the standard cycle.
- So the feature freeze
is also solving a sort of
mechanical, technical
problem that we realized
when we were standardizing C++ 14.
At the very last meeting
we had an insane rush
of late proposals that
were hardly essential,
so it was a big problem
for the co-working group
and well since I still happen
to have a membership card
for that group and the
chair is a very good friend
of mine I told him that
I will make some effort
to fix this problem so that
you can actually focus on
on finalizing the standard
as opposed to having
an constant influx of completely
new material at the very end.
So we actually had an
unofficial feature freeze
for 17, now we actually
have a plan that contains
that feature freeze and
we have voted on it,
so we're expecting to stick to it.
- We've got a lot of questions.
Can you be brief?
We've got a lot of
questions I want to get to.
- There's a pipeline going
through the committee,
from study groups to working groups
to the groups that does the final text
like the library group
and the co-working group,
so if you put something into the pipeline
it comes out several months later.
Apart from that there are
things we don't discover
till we integrate it into the final text.
We need a feature freeze to be able
to deliver a quality product.
It's not that different from
any other major product.
- I mean I completely agree
that a freeze is a great idea.
I was just wondering
what procedurally mean,
does it roughly mean
don't make new chapters,
but it's fine to fix
wording or what exactly?
- The wording gets changed
up until the committee graph
goes out and then response and B comments,
but yeah new features
there's a deadline for,
a deadline coming up
very soon for actually
voting new features into C++ 20.
- So we have actually
specified what it means.
San Diego is the last meeting
where we look at papers
that we haven't seen before.
- That's what it means, all right.
- Thank you.
- Thank you.
- Hello and thank you
for all your hard work
because I'm sure it's a tremendous amount
that we see the very tip of,
but as far as I'm aware after C++ 11
you guys radically changed
how the standardization works,
study groups, TSes, working
groups, so two parts,
do you think that change
has been working very well?
I mean I don't have an
opinion, it seems like it's
working to me, but what do you guys think
and if you could change
one thing about the way
that the committee works
or just standardization
in general, if you could wish
something into existence,
what would it be?
- Since I have a microphone
I can give you a short answer and that was
before C++ 11 we had one
release in eight years.
Since C++ 11, we've had
three releases in six years,
if you count 11, 14 and
17, and we're going to have
another one in three more
and from that point of view,
the rate of change has sped up a lot.
But that's just one point of view.
I'm sure everybody else on
this stage has more to say
so I will hand it off.
- We've tried the TS process since 11.
We haven't been quite so
uniform about what that means
and what the bar should
be for getting anything
into a TS, Titus clarified
recently something that was
great, a TS should answer a question,
so you should write it
upfront, it was you?
- Not me.
- Oh, all right.
Someone.
- I agree.
- Someone came up with
this rule and it's awesome.
Excellent, there, okay so--
(audience laughs)
Right, so we haven't been
so good about figuring out
what's the bar for getting things into TS
and then managing the
expectation that things
that go into TSes does then
just then role into the IS
right away you know so I think every TS
has ended up having a unique
cultural environment around it.
And so we'll still trying
to figure this out.
The three year model is also great,
but and the committee is
not a corporation obviously.
If it were a corporation though,
it would be a little more
Zen about fretting about
loading everything at the last minute
because a train is shipping and oh my God
there's not going to be any more trains.
There is going to be another train,
and it's just whenever
things are ready, they go in
and if a train is not ready today,
just don't cry over spilled milk.
It's going to be ready next time.
Of course it's going
to be ready next time,
like if you think it's
close to ready this time,
for sure it's ready next time.
So don't fret too much about that,
but actually yeah yeah,
actually every three years
we have a massive
argument about everything
must go in right now.
That could be improved.
- There's disagreement on
the stage about whether
the concepts and modules
TSes were successful.
However, it's unambiguously
observable that they allowed
us to fix certain problems
that we couldn't anticipate
and had we actually adopted
those features sooner
we might have ended up in a
much more problematic situation
than where we are today,
so yeah it was painful.
We would have liked to
ship concepts a lot sooner,
but some of those fixes were
actually really, really good
and the ability to ship a specification,
gain implementation experience
on it was overall positive
in my opinion Bjarne might disagree it.
- I have some opinions yes.
One of the opinions is that
moving something into the
standard creates much activity
and many improvements.
Moving things in actually can
make things improve faster
instead of endless discussions
about whether you move it in.
By the way I'd like to
point out that between
the 98 and 11, essentially
nothing happened.
03 is something I never say because
it is really hard to pin
down anything that was done
except for clarifying some text,
so we are really talking about 13 years
and since we were aiming
at 08 or thereabouts,
we slipped four years while
people saying oh we must
delay for a year while
we get this feature in.
Yes, it's difficult to ship on time.
Yes, people scramble to get things in.
Yes, not enough features
go in if after my opinion
in some cases, but we are
doing much, much better.
We are shipping every three
years instead of slipping four.
- Can we okay let's
make this the last one.
- Let me just add to that,
because I was one of the people
who pushed hard for that and
the committee graciously let me
convince them to do it
and I wasn't the only one
who spoke in favor of
it, but it took a lot
to reorganize that way, TSes, absolutely.
We could use them better.
Everybody uses feature branches.
Everybody understands
feature branches are good.
Yes, some people say I
shouldn't have used that
feature branch for this thing.
It should have gone straight into trunk.
- That's the discussion--
- 20/20 hindsight.
- We're having about and
a TS is a feature branch,
the IS is trunk and it's
exactly the same thing.
So there's no argument that it's good,
it's just you learn how to use it best.
It's a tool, the biggest improvement about
shipping every three years,
people who weren't living
in the decade of the 2000s in C++ land,
or who were, but have
moved on may have forgotten
that a lot of people wondered
if we were ever going
to ship another standard.
That is one of the big reasons why
people were surprised
that C++ 11 came out.
C++ changes, I thought
it just is what it is.
It's also why compiler vendors
were slow to implement things
because they didn't know if
they were going to change
yet again our value references anyone,
changed three times before
we finally shipped it,
so the fact that we're shipping regularly
is one of the reasons why
people know what to expect.
It's predictable, if you
say when you can't say what
exactly will be in each
bucket, you know it's going
to ship again and it
should release pressure
as people get more used
to it, as Olivier said
that okay if I don't make
this train, the next one
is about to load, we
should learn culturally
that that's an okay thing,
but the predictability,
look at the world today, we
have today all major compilers
are conforming to C++ 17
within a year of the standard
shipping, that has never happened before
and it's because we're
shipping predictably
and the world can rely on
us and so we really need
to keep doing that part of it.
(audience claps)
- I have an anecdote that
speaks directly to this.
I was the author of a proposal for C++ 14.
I thought it was a significant proposal.
I still think it's a significant proposal.
It's the searcher's proposal,
the buoy or moor stuff
that the advanced, the
extended STD search,
it was in the library of fundamentals TS,
we were going to put it in C++ 14.
It was being discussed and the
wording was being discussed
at the very last minute
because the train was leaving
and now or never and
we found some problems
in the wording and there
was something that I knew
how it worked, but I couldn't describe it.
I couldn't describe it to
everybody's satisfaction
and so I went away and
walked around the block
in Bristol a few times and then came back
and said okay, take it off the table,
because if we can't get the wording right
and I realized that there
was a chunk of technical
explanation there that I didn't understand
and I had to go away and think about it
and I realized later that
there was something wrong
with the proposal and I had to change it.
And I came back the next
meeting with an updated paper
and it sailed right into C++ 17,
it was a better result,
I mean three years later,
but it was the right proposal.
It was the right design
as opposed to this thing
that was kind of hand wavy
and wasn't quite really
I knew what I meant, but nobody else did.
- It's not good for a standard.
- It's not good for a standard.
- [Jon] All right, thank you very much,
let's get the next question.
- Thank you.
(audience claps)
- Hello, one of my few big
takeaways from this morning talk
was that auto could be
considered like the weakest form
of concept and that maybe
in the foreseeable future,
it could be seen as something
like from the legacy past
or even like a call spell
that we would need to replace
with straighter concepts and I'm wondering
are we seeing some kind of dial back from
the almost always auto we
preached in the past years?
Because I'm still upgrading
sometimes code lines
to C++ 11 and I'm still
getting some defensiveness
from people who come from C++
03 and are worried about auto
so I'm worried is that going to give
them more arguments against it?
- I will say something,
because in the first day
of this conference half
the people who stalked me
have a question about almost always auto
and I partly am responsible
for coining that.
Let me say here on camera
and hopefully clear this up.
What I said at CPP Con
number one four years ago,
but I understand that the
auto type deduction thing
obscures this, when I
say almost always auto
the number one benefit from
that there are many benefits,
but the number one
benefit is that you cannot
forget to initialize,
you simply cannot write
auto x semicolon, it doesn't compile,
you must says equals
something, you cannot fail
to initialize and that
includes if it's an int,
if it's a double, if
it's a vector, whatever.
When you see that, the almost always auto
a lot of people say auto
because you want to reduce
the type and obscure the type,
no because there are two
forms, auto x equals expression
where sure deduce the type
if you want to track it,
but there's also auto x
equals type paren paren
and then the expression in it,
you put the type on the right
so the point of almost always auto,
which by the way with
guaranteed move elision
in C++ 17, now there are no
cases where you cannot write
auto, so it's actually now always auto,
double A batteries are
bigger than triple A,
so this is an upgrade,
the purpose is not always
to deduce, as if you never
needed to know the type
you're talking about, the
purpose is simply syntactic
because auto is the thing
you put at the front.
If you declare your variables that way,
you can still put the type
it just goes on the right,
but you can't forget to
initialize and you get
a bunch of other benefits.
(audience laughs)
- And totally separate,
if you use auto you can get
confused about what type it is
because the information is not there.
That has been observed in the wild
and concepts addresses exactly that point
and not the others, because again you must
initialize something where
you just specify a concept.
It just gives you the readability back
and it gives you the constraint.
I want an input channel.
I don't want any old stuff
that comes out of it.
- Thank you.
- Compliments.
- I think we're actually
in violent agreement,
because today with almost always auto,
even without concepts, you
can say a concrete type.
What concepts is let you do is to say
I want any type that satisfies this,
both are declaring a type-like constraint,
not just deducing anything
and that's the key point.
- It's just in many, many cases,
you don't want to pin down the final type,
you don't know it, especially
when it's a cause or
a function that might
be a generic function
so you pin it down too
tightly if you mention
the exact type.
- Let's make Ville
make the last comment
and then we'll move on.
- Right, I do have a proposal that allows
using auto as a parameter type,
so that will eventually extend the realm
of auto cases that you
might be concerned about.
However, the convenience and the ability
of being able so being able to do that
at least for me trumps the concerns about
potential misuses because
it happens to be very useful
to be able to write functions like that.
- Thank you, so the takeaway would be that
until we get better concepts,
auto is still the way to go?
- We have concepts that are coming.
(audience laughs)
They are in the working paper
and the case of Ville auto
I mean also want to propose
they put in 2003, so it's not a bad thing,
but it can even better
when you use concepts
because then you can anything
that matches your expectation.
- Thank you.
- Hello, if you have a magic
wand and you gave yourself
some latitude to have fun,
that allowed you to remove
something from the standard,
what would you remove?
- The time machine question
I think I'll refuse today.
(audience laughs)
- Macros and the way you
do it is by finishing
the process that we've already started
of having replacements
for the important uses.
- CTAD, constructor
template argument deduction.
(audience claps)
It's not great, it's not
great, like every snippet
of code that I've ever seen save for one
I have been like, ooh,
I would not be happy
with that in the code review.
That is a feature that came
in at the end of a cycle
because we were rushing and
I'm really sad (winces).
- Since you asked a loaded question,
I wouldn't actually want
to remove the facility,
I would just like to
rephrase how it's done
and that feature is volatile.
(audience laughs)
- Papers welcome.
- Yes.
- I would really like to
make it not be a CV qualifier
as such so that it
wouldn't mess with what is
a copy constructor and what
is not a copy constructor.
- It sounds like a great paper.
(audience laughs)
Ah, I got one for free
just now, the dirty basement of SG1
is full of signal handlers
and thread local storage
and volatile and honestly--
- One thing.
- Ah damn, memory to consume.
(audience laughs)
That's it.
- Is that as bad as the basic?
- The basic, yeah.
(sighs)
(audience laughs)
- No, it's not as bad
as the other things.
- Okay.
(audience laughs)
So CTAD, CTAD I think is--
- You don't have to explain
so we go on to the next question.
- No, I don't template argument
deduction and deduction
guides my real objection to
those is the same as Titus.
It came very, very later.
We didn't understand all the implications.
We're still sorting them out.
If it had shown up in
2015 instead of 2017,
actually if it had shown
up in 2014 instead of 2016,
I think we'd be in a much
better place right now,
but you wanted a short
snappy answer, alright pair.
- I want to have fun.
- Okay, this is it,
this is it.
- I should point out
for correctness sake
that CTAD was a proposal
aiming for C++ 14 so it
did appear at the time.
- [Jon] No, we're moving
on, we're moving on,
we're moving on.
- Sorry, sorry,
the proposals to add it
to the standard library
showed up in the last meeting for C++ 17.
- And I'd like to point
out that a fair number
of those deduction guides become redundant
when we've got concepts.
(audience laughs)
- All right, next question please.
- Thank you.
- So--
- And it was ready.
- Okay, so after
the time machine question, so
clearly C++ would have been
a different language if
you all had the experience
at the time it was
started, so I was wondering
did the committee ever
discuss the possibility
of working the language
in an API-compatible way
to because adding new
features like 90% of the work
like Bjarne said is to
integrating with the rest
of the language, having less
legacy would help a bit,
so that's why I was wondering.
- There was stood two briefly,
it's not a language level fork,
but at a library level, there
was a solid discussion of
no, there was a little bit of
discussion along those lines.
It's never worth it to invent a new one.
It is always a seductive
sort of like siren
of oh yeah, you could just
ignore all of your legacy,
just rev you version
number you'll be fine.
It is a terrible idea.
So I don't believe the
committee has ever discussed
anything like forking language
and boy should we not.
- So we have occasionally discussed that.
(audience laughs)
Not actually in the form
of an actual proposal
because the idea gets
shut down fairly quickly.
Stability and backwards
compatibility are major
features of this language
and they are huge
numbers of industry users
that rely on those things.
We cannot just sort of
casually think that oh,
hey, let's all go modern and sexy
and break every user that we have.
- Okay, this has been interesting.
We're now at under 30
minutes and I'm going
to be much more heavy handed, go ahead.
- Yeah, I have a question
about context per,
because if you write
a context per function
you cannot be entirely
certain that this function
will be executed at compile time
and now there is this new
proposal I saw at context
per bang, but I discovered it,
I mean the impression that
I discovered something,
if you return the type
that only makes sense
at compile time, so you
set integer sequence
from this context per
function, then that enforces
compile time execution, is it indeed true?
Or is it something that I just
observed in a couple of cases
where I was lucky to observe the writing
and then in a Black Swan case
it still executes at run time?
- I don't actually know the
answer to your question,
but I'll point out that the
model is that you can do things
at compile time, by saying context per
you reduce the complexity
of the function to the point
that if you give it context arguments
it can be calculated and you
make sure that the compiler
keeps the source around
so that it can do it.
Without that the compiler's
memory space could explode
and also you could get functions
where you are very surprised
because the compile time
evaluation can be strange.
You can force compile time evaluation
by assigning to a context
per variable or to a use
it in a context per context.
That's the model that it was.
It was never meant to
guarantee in all cases.
Now we are working exactly
on that, there are proposals
that has been approved
in the evolution group
to force constant expression evaluation
and we'll see how that works out.
- So the situation you
describe returning a type
that supposedly only ever
makes sense at compile time,
while that's not accurate,
it makes little sense
at run time, but using such
a type as the written type
doesn't guarantee context per evaluation,
you will get run time code
whether that makes sense
is a different question.
- Thanks.
- So you mentioned
that the committee groups have
already been here for several
days discussing things,
is there anything you're
able or willing to say that
they've managed to achieve
or what they've been doing?
- Let's see, I think I can summarize
for the module discussion.
We settled a lot of the issues
that look somewhat minor
and very obscure, so that
I can't really explain
what they really have to do
with, but it has to do with
how are you doing include files, preambles
and what are the exact lookup
rules in obscure cases.
There will be a paper
co-signed by the four
people that are implementing
modules just now
for resolving all of those issues
to be available in San Diego.
- So that--
- So--
- Gets, yeah, he was
there so he can answer it.
- So we made very good
progress on couple significant
pain points, which are
name lookup in templates
exported from modules and
the ability to be able
to export in complete types from a module
without having to split your
code across multiple files.
These were fairly significant pain points,
and I'm not going to give
you any hard promises,
but there's going to be
a concentrated effort
to put modules into C++ 20.
- Thank you.
- Okay, next question.
- Wait, there was another
committee meeting.
- That was them.
- That was modules, okay.
- Let's talk about okay sorry.
- That's just one meeting.
- Right, so that was Thursday and Friday.
Saturday and Sunday was SG1, we were there
to talk about executors,
executors are sort of an analogy
to allocators for execution
and they're a cornerstone
for almost everything we
want to do from here on out
in the concurrency and
parallelism study group.
So they're a foundational
technology that everything else
has expressed a dependency on.
So we're more or less dead in the water
until that comes to fruition.
We were driving to maybe hit 20,
or barely miss 20 with executors right up
until the last meeting
and then we had to have
surprise major change proposal appear
which forced us to have
this extra today meeting
to sort of metabolize
that and I think I think
we made fantastic progress
in the sense that our
long-term direction has now I
think dramatically increased
in quality and clarity,
but it is now too big
to make it through 20, or
there's too much new work
that needs to be done to hit 20.
But because of that, that
actually created a lot
of interest in a very narrow
compromise that we could
ship a very small subset
of what we now understand
more clearly as the bigger
picture and ship that
very small subset in 20, so
that is still a long shot.
I think we're going to try and
get the paper in in two weeks
it's very tight, SG1 is
very far from the draft,
from SG1 we need to forward LEWG.
That needs to get forward
to LWG and then that can
be voted on, if we move
one room per meeting
we're going to run out
of meetings basically.
- You have my room and my ax and my bow.
(audience laughs)
- [Jon] All right thank you very much.
- Thank you.
- I think it was great
progress and it looks good.
- So in recent years, we
got LLVM and LLVM allowed
us to write nice little tools to do stuff
on our specific code
bases and it was great
and I've heard Gabriel
standardizing something,
which basically is an AST
for C++ to represent problems
and we can do transformation
pass over them
and use of that, what's
your opinion or idea
of having a reference
implementation of maybe
the compiler front and
the standard library
so we could have one true thing to look at
which is correct at all times.
- So you're volunteering
to write it, right?
- There is--
- I've got half of
a front-end.
- There is a lot
of obvious value in that and
even more non-obvious work.
- Yeah, it's a lot of work.
- And that has been proposed
for almost 30 years, it is
virtually never going to happen.
The reason is because first
of all you'd have to bless
an implementation, keep it
in sync with the standard
and you might have noticed we
struggle to ship the standard
in the same way, so
there's just no bandwidth.
The closest to that is
compiler test suites
that companies like Plum
Hall and Perennial make
and the bug list and issue
list of the various compilers
as they compare with each other.
- All right.
- So you said an
implementation that's always correct?
(audience laughs)
Unfortunately, I have bad news for you.
- Yeah.
(audience laughs)
- Contrary to the popular
belief, Smithy isn't perfect.
His implementation has bugs.
So does the one that I
work on, so I think that's
a slight oxymoron to have an
implementation that's always correct.
It's beneficial that we have
multiple implementations
and multiple different
people reading the spec
and implementing and
then providing feedback
on whether it's crystal clear or not.
- It's a pain in the neck
not being a monoculture
because there's so much
that has to be done,
but it's hugely important for
the long-term life of C++.
- One of the things that
gets the core in the LWG
groups really interested in a problem
is when somebody says we have
implementation divergence,
which means that different
groups of implementers,
whether it be compiler
implementers, library implementers
have read the same words
and come away with different meanings.
- Oh, I've been there,
I've implemented a library
and I've come to different
conclusions to the wording.
- That means that the words
in the standard are not clear.
There's a bug there.
- Exactly.
- Either that or somebody
is just smoking crack.
- Let me give one quick analogy.
- Or maybe and is the right word there.
- You know how you may have heard how
in some high integrity
systems, say space vehicles
that you don't just have one processor.
- Yes.
- You have multiple processors
and they vote.
- Yes.
- That gives you a much
more reliable system
than even one perfected
processor and that is the C++
implementation landscape today.
- Correct, yes, that's a good analogy.
- I wanted to say that,
but you said it better.
- All right, thank you.
- If we have just one
implementation, it will be sorry,
I really think that the
best thing about C++
is that it's not a monoculture,
because otherwise we
would have the situation
where we would say not
about works as coded.
- The two features that excite me the most
would be modules and the meta classes.
I'd like to hear about
two features of yours,
one that's almost coming
and one that I probably
haven't heard about that
excite you the most.
Question to everyone.
- Of the features that are
currently in the pipeline,
actually my two favorites
are one that's already
been accepted for C++ 20, contracts,
and one that is getting
close to the standard,
which is modules, those are
the two of my favorites of the
ones that are actively in flight
in the core groups right now.
- Quickly.
- So--
- Modules and concepts.
- So yeah sure
concepts as opposed to
making generic programming
palatable, they make generic
programming possible,
so it's something that
I can't wait to have.
Reflection eventually is going
to be a real game changer.
- [Jon] Okay.
- The parts of a standard
library that throw exceptions
are not usable in contexts
where allocating memory
isn't acceptable, do static
exceptions offer hope for
this use case of the standard library?
- That's my proposal.
It has not come to evolution
yet, it is very early days.
We hope to solve those kinds of problems,
but it's very early, it's
mostly been incubating
in study group 14.
- Thank you.
- So we may talk about that kind of thing
more tomorrow or Wednesday.
- So you do have any examples of feature
which you want to see in C++,
but which can't be implemented
because of some compile
developer say sorry
we cannot implement it yet?
- I work with a compiler that
does not yet implement concepts.
- But it can be implemented.
- They can implement it
and I believe it will
be implemented soon, but not yet.
Maybe I have misunderstood
your question then.
- I mean fundamentally
everything in the standard
that's listed as no diagnostic required
is an indication of this
is definitely a problem,
but it would require us
to solve a really, really
hard programing problem,
maybe the halting problem
to actually force it to
be a compilation error,
so effectively like a significant part
of the undefined behavior landscape,
like everything ODR related
is the answer to your problem,
the answer to your question.
Right like if we had infinite
magic for the compiler
we would stop having ODR problems
and that would be actually
way, way, way more important
than most of the things.
- When we get modules,
we'll have real ODR.
- When we get modules
and rewrite all of the
legacy code in the world.
- Good.
(audience laughs)
I'll tell a story, this is important.
I explained what it would take
to use modules really well
to some senior engineers and they said,
"Great, we'll have to
rewrite all of this code
"that our managers wouldn't
allow us to rewrite.
"We can finally clean up our messes."
I was shocked, then I
went to somewhere else,
told the same story, got the same results.
I've done it three times with people
that apparently haven't
talked to each other.
This is an opportunity.
(audience laughs)
(audience claps)
- It's what I'm disappointed in.
- Yeah, Titus's comment actually that
the phrase that strikes
dread into my heart
all the time is IFNDR, ill-formed
no diagnostic required.
Your program will compile,
it's broken a priori okay.
It's like and we're not going to tell you.
It's a terrible place to be.
- We're working on it.
- It's not undefined behavior,
but it's like undefined behavior.
- Okay, thank you.
- Hi, it's me again.
(audience member yells)
No one else was in
line, so I've asked this
every year that I've been
at the Grill a Committee
and so about the restrict qualifier
(audience laughs)
where is it, how is it
doing, who is working on it?
Is it coming?
- I received a paper.
- Is it dead?
Which paper because I've
got 33 that I'm working on.
I can only bring 12 to San Diego.
- You have a paper on this trick?
- No.
- Are you just asking for
someone to do your work for you?
- In this case, yes, but
also someone was working
at some point because Herb said
someone is working on this.
- Oh, cookie licking is bad form.
Just because someone else is working on it
doesn't mean you shouldn't be too.
- I wasn't allowed to work
on papers until this year.
- No alias must go,
this is non-negotiable.
- One more time, sorry.
- That was a quote from
Dennis Ritchie about the first
version of restrict.
- Mm-hmm, okay.
- It cannot be defined well.
It can be used in particular
areas and particular contexts
and the committee has looked
at this a couple of times
and it's come to the
conclusion that people
that wanted it already had it.
- So there's always the option of prodding
the authors of that proposal
and asking them how it's doing?
- I don't know who is writing it.
Herb just said that someone is writing it.
- I don't want to burn innocent people
in a public forum like this,
just look at the previous
proposals on this subject
matter and contact the authors.
- But that would require
me to read things.
- And I don't know of
any active one this year.
- Okay.
- And super pro tip,
wg21.link/index.txt gives
you a searchable text file
of all the paper numbers and titles
so you can.
- But then I would have
to read things.
- Right? (mimics exploding)
So you can find on page for restrict.
- The end paper bot.
- It breaks all
the time though.
- Google site search.
- I don't know.
- That's what I
I mean the link he said, but just type any
good search engine
site:open-std.org restrict.
- So you're telling me that--
- You can even go just to--
- I can use Bing.com--
- The WG21 committee,
and then that will search
the paper bodies as well.
- That sounds like a better option.
(audience laughs)
- He's telling me to use
Bing, I'll Bing it okay.
- Hi, so I read Bjarne's
paper Remember the Vasa,
so that paper that's released on papers,
but I don't see much data
proving those papers don't work
well together and I also hear people
have different interpretation
on what does a paper mean,
so can you or the direction group
tells me that kind of
message you want conveyed
surrounding paper?
- That paper
actually had a conclusion section
and I have noticed a lot of
people commenting on that paper
without reading it at all
and so there was a lot of hostile comments
and a lot of wild cheering
from C++ haters about it,
but my point is that you
cannot have everything
and I looked at the
mailing before I wrote it.
There was 43 papers that in my opinion
would change the way we wrote code.
We could not handle that
much in any reasonable time
and if we as a committee did it,
the communicative could not
have solved those lessons
and used the facilities well.
The language would become
unmanageable and unteachable
if we accepted all of those 43 papers.
I was quite clear that three
of them I would support,
but the point is we have to make decisions
we have to decide what we do
and my recommendation was to work
really hard on proposals
that would be foundational
and actually approve the language as used
and as used in the future.
That was my main reason.
I fear the number of minor
features that are undoubted
conveniences for somebody, somewhere,
but each of them has a cost
in teaching and understanding
and there are too many in my
opinion small conveniences
that doesn't bring the world forward.
And I don't doubt that some of those small
improvements are significant also.
Auto was a really good improvement.
Range four was a really good proposal,
so it doesn't have to be big and massive,
but we have to look at what
will bring the community
as a whole forward as
opposed to what can be done.
There are so many things that can be done
that in the end would sink our ship.
- Thank you.
- So we've cleared
the questions if anyone has a question,
there's not much time
left, but we could probably
get another question,
but I've got one for you
and something that was
referred to earlier,
the size of the committee has
grown pretty dramatically.
Is the size too large, is it too big?
- I will say that I chair one of the
that's pretty much the smallest group.
My group is not too big.
I would be happy to have a
few more people in my group.
- I have a very simple answer to you, no.
- And my answer is the opposite.
Of course the committee is too big.
You can't really get agreement
among 150 people easily.
On the other hand,
there's absolutely no way
of reducing that committee.
It is a result of
enthusiasm and no manager
could pick the subset of
that will be more efficient
in getting things done, so
this is just the way we are
and we should be happy about it.
- So I am actually not
that concerned about
the increased difficulty
of having agreement
in the committee because
I think that the more eyes
we put on possible bugs, the
better end result we'll get.
- I agree, but we also get
many, many more proposals,
because most people who
come to the committee
want to at least have one
feature added to the language.
- I was going to say something similar.
I think we could a lot
of people could join.
That's a not problem and
the quality increases
dramatically with
participation, but the workload
also increases with
participation and our pipeline's
structure has stayed
the same over a doubling
of the workload and so
with the same I hate to be
hardware-y, but with the same pipeline
that we can't clock as fast.
(audience laughs)
So so
so
so some day we will have to restructure
the execution graph of the
committee if we keep growing,
but this shouldn't slow people down.
More people should come.
- I'll just point out that
you're a hardware guy,
everything's a hardware problem.
To us software people, it's a software.
- I would also encourage
yes, more people should come,
but more people should
come without an agenda
and having read the ini
and having understood
what C++ is for, because we fail at that
and I fail at that when I first
was part of the committee.
Like C++ is here to be the language
where there is nothing,
no room for something
more efficient between
us and the hardware.
C++ is the language to be you do not pay
for what you do not use.
C++ is not the language for
you cannot possibly misuse it.
And so especially like
coming to the committee
from a perspective of I
run the Google style guide,
I started trying to prevent
all possible misuses
and that was the wrong choice.
That's not C++, we need defense and depth.
The language needs to
enable all of those things
for efficiency, and then
you need style guides
and linters and best
practices and senior engineers
to tell you no, dummy don't
do that and that's fine.
That's actually working as intended.
- [Audience Member] More
people, less papers.
- And don't forget the
abstraction mechanisms
that allow you to get away
from some of that messiness
in a way that suits your needs,
not the machine's, not mine.
- [Jon] All right, we've
got another question,
let's go ahead.
- So co-await is there
because we're afraid of
using good key words.
Is this really the lesser evil?
- What co did you say?
- He said co-await.
I have I think said in
public that co-await
is really close to a
oh I hate this so much.
Unfortunately it comes
as a triad of co-await,
co-return and co-yield?
- Does not make it the better.
- Does not make it the better in any way,
but I seriously spent a
solid week this summer
trying to come up with a triad of options
that actually fit together
and that we hadn't already
squatted on any of those names
and if you have a
solution to this problem,
I would love to talk to you,
because I hate co-await with
the passion of 10,000 suns,
but I don't have a better option.
- We need key words and all the good ones
have already been taken so we get context,
but we get deco type, we get co-await,
which I happen not to hate.
- Can we take them away?
- Sorry?
- The keywords.
I know it's a hard problem
to take keywords away
from people that are already using them.
- The standard library uses them already.
- So we consider trying to take yield.
It's impossible without
breaking half of the world,
so naming is hard,
grabbing key words is hard,
sometimes we need to make
imperfect compromises.
Get over it.
(audience laughs)
(audience claps)
- I don't think we're going
to get a better answer
and we're almost out of time here,
so I want to thank you
guys all for being here,
sharing your thoughts
maybe giving some insight
into the process and maybe
some insight into the future.
I want to thank you
guys for great questions
and we're looking forward
to seeing you tomorrow
for another day of CPP Con
so thank you for very much.
(audience clapping)
