- 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)
