- Good evening, I hope everyone's having
a good conference so far.
- [Everyone] Woohoo! (clapping)
- Alright. Very Good. (clapping)
So tonight is Grill the Committee.
This is your opportunity to ask questions of the people
who are defining the architectural language
of language in the news, what?
- There's some kind of echo.
- Um, can you guys work on that?
- What's wrong, we heard (giggle).
- There's some kind of echo,
can you maybe take me down a little bit?
My wife can help you with that 'cause she's been trying
to take me down a lot, anyway. (laughter)
So, this turns out to not be the entire committee,
I'm not certain we can put the entire committee
on this stage, but we have a few individuals
that are gonna have to bear the brunt of the grilling
for this evening.
I want to talk about why the particular individuals
that are here, are here.
So we have, Titus Winners is the incoming, just ask
just a second ago, give the correct title, the incoming
Library Working Group Chair.
- Evolution. Library Evolution. Alright.
So I managed to screw that one up.
Let's see if I can screw it up for Vilet, too.
Okay, he pointed out, I referred to it as Core Evolution,
of course they don't call it Core Evolution,
they just call it Evolution.
He is the share of the evolution working group.
Is that right? Okay.
So these two and Herb, who is the convener of the committee,
everyone is here because of a particular feature that
they've been associated with to champion.
So, first question I'm going to ask you is, to introduce
yourself and talk about what that feature is,
what it's status is, how far along is it, where are we at,
and I think most, I hope most people know the details.
I don't think we have to go into that.
But just tell us a little bit about the features.
- My name is Andrew Sutton.
I am the Project Editor, well, formally the Project Editor
for the Concepts Technical Specification.
I help bring concepts into C++ 20.
Half of it, anyways.
And important subset I got into C++, we are still trying
to work out the remainder of it, but hopefully that will
happen by C++ 20.
- So the status is...
- In half.
- It's voted in the working draft for 20?
- Yes. The working draft has been voted into C++ 20.
Although the working draft lost half of it's weight
- Well, trust me, loosing weight is not an easy, okay.
You can pass, I've already introduced you Titans.
- My name is Louie, I represent Amazon on the C++
committee, I'm also a member of the Canadian Delegation.
And I work mostly on language level support
for meta programming, so making template meta programming,
I also do some tweaks to make Lamdas better,
like template Lamdas.
And stuff like that.
- So, my name is Ira Deebler, I work for Facebook.
I am the prime mover of the Rangous Technical Specification
and former Project Editor.
The Rangous Technical Specification was sent off
for publication at the last committee meeting...
Super excited about that, which means that I can stop
having to process book reports on the Rangous
Other than that, the Rangous work is based on my
Range Fee Three Library,
the Rangous Technical Specifications is only a small
subset of it, so I still have plenty of work left to do.
- Okay, I'm Gabriel Districts, I work for Microsoft
on the C++ team.
Currently, I'm the Project Editor for the Modules
I did last summer's meeting in Toronto, it was sent
out as a PDTS ballot, PDTS means Proposed Draft
It's a long ballot, and I hope that by Albuquerque meeting,
which is in November, we'll get all the votes and hopefully
we'll move on to the next stage.
Which is we'll move to publication assuming things
work out properly.
Modules from my perspective, they allow you to organize
codes at large scale, not at small scale.
Small scale has classes and then spaces to organize
the code, so we're talking about when you have large
organizations and a large code base,
and you want to put some structure there.
The goals are compromisation, better soft architecture,
isolation to allow better bureau's reports,
and semantics that were software developing tools.
Those I believe are very important.
We need to think more about the tools that will help
us be more productive.
And a law that requires of us to be more picky
about how we practice, how we write programs.
Code hygiene is very important.
The techniques that we've learned, used in the past,
20-40 years will need to take a hard look at them.
I'm looking at you macros, I know it is controversial
issue, but I would like to encourage the entire
C++ community to think hard about how we write code.
- Okay, I'm Piano.
I try... (clapping)
I try to think about the whole language, including
the library and where we're going over the next few years.
I was sitting here and thinking that the group in this room,
is roughly the size of the active members of the committee.
Not every body turns out at every meeting,
but this is the influential size of the group.
So how do you make a consensus for doing something
new and interesting and forward looking in a group
this large where everybody has some old stuff
they would like to protect?
That, I think, is a fundamental problem.
Having a group like this, agree and have a consensus
is very, very hard.
I'm in favor of some proposals, usually proposals
I have worked on four, five, ten, twenty years.
I would like to see concerns, all of concerns, not just
the backward looking bits.
I would like to see simple static reflection.
There is simple functional stuff, nothing fancy.
I would like to see much else, and as Gabby said,
modules that really promote hygiene so we're not stuck
back in the mid 70's with your macros infecting my code,
and my type divs changing the meaning of your code.
These are hard, hard things.
I would like to see range proposal including the good bits
that they haven't put in yet.
So, I try to look out for the whole language.
It's hard briefly to talk about the whole language,
but it's moved forward.
The community as a whole lives among other communities,
and there are strengths that we have, and strengths
they have, and we can't just rest on our morals
and assume the world isn't changing, because it is.
And we have to face new challenges.
- My name is Gordon Shannoff.
I work for Microsoft.
My official title in the committee is the Project
Editor of Core Routines that was sent for publication
for Dr. Ronter.
Core Routines I think completes your mission of bringing
stuff from Semore to C++ because it's one of the features
that was there.
And let me, I think I know what you are going to say.
I will say it.
- Don't. - Go ahead.
- I was just going to apologize for not mentioning
Core Routines and especially Fast Role Routines
because they hadn't been mentioned this far, sorry.
- I was going to mention that actually C++ had Core
Routines, or more precisely, the was an AT&T desk
library which funded C++ development, and it was by
Bern, and you can download the AT&T desk library
presentation, I found it on the web.
- It's stored under history.
- So Core Routines counseling purely making `a facility
for expert authors, but before C++ go into shapes,
we'll work out great library types which may
make things easier.
And we'll beautiful interactions with rangers,
I think Eric was more recently had some fun and and plus,
we had networking and all those things tied together.
And yeah, that's it.
- I'm Herb, Herb Setter, I do a lot of administrative
things and running the committee and herding cats,
although people like Veda and Titus help a lot
with the pre-Titus is Jeffrey, or Titus is the post-Jeffrey.
We're sort of in that middle phase right now,.
But, I also have worked on a number of C++ proposals,
Dolpointer, Lamda Syntax, Eden Class, a lot of those things
you can blame on me, or delegating constructors,
or partly on me.
And, right now I'm mostly interested in, and I dearly hope
in my technical contribution, to be able to spend
the next decade or so, on making C++ code simpler.
Even as we evolve the language, which can only be done
compatibly by adding to it.
And I think it is possible to add to the language,
to evolve it, because it is a living language
that is widely used, continue to be used, needs to continue
evolving, but also make C++ code dramatically simpler.
So I think that's possible, and I hope to continue
working on that.
Some of those effects are at the research stage
right now, and I'll talk about some of them on Wednesday.
But, I think that will be essential for the future
of C++ and I'd like to contribute toward that.
- Alright, thank you guys.
Alright so, the format this evening is for you guys
to come down and ask questions.
And I'm going to ask them some questions while you guys
think of the questions you want to ask.
I'll tell you this.
We will probably be pushed for time at the end, so if you
think of any question, you want to get down here quick.
Alright so, first thing I want to ask,
is you guys particularly are all associated with something
you were pushing for, but in the committee,
you could almost think of it as you wear two hats.
You were a hat where you're trying to push a particular
proposal, and you wear a hat where you're trying
to push back on proposals.
'Cause that's the game, right?
So, I want to ask you to think about a situation
and you don't all have to come up with this, but if we had
some interesting stories that's what we'd want tonight,
where you got pushed back, where you first thought
it was kind of ridiculous, okay I'll think about
how to deal with that, and then realized, oh wow,
this proposal has really benefited because of something
I hadn't thought through well
and at first, it wasn't an oh wow, brilliant!
At first, it was like an (growls).
But then you said, no no, now I realize what's going on.
Anyone want to fess up to that? Microphone! (chuckle)
- So, the Rangous TS was born out of some early work
that I had done on ranges, and I floated it on the ranges
discussion list, there was a working group, and I thought
my ideas were terrific and I thought everyone should
listen to me.
And then, this guy named Sean Parent came along on the list,
and corrected me, that my ideas were not, in fact,
all that great.
And he had some better ideas.
So, I was extremely resistant, and so was Sean,
he's a remarkably difficult person to convince.
And so in the end, I ended up changing my proposal,
and you know, I would be generous to myself
and say we met somewhere in the middle.
And I think the proposal is infinitely better,
for Sean's feedback, despite that initially I really
didn't think very much of his ideas.
- Thank you, thank you.
Anyone else want to share, yeah?
- From my perspective, I think it' the wrong question.
- Because, - I'm willing to be corrected.
- My ideal way of having proposal develop, is that you
articulate a problem, and then you articulate sort of
a first idea of how to solve that problem.
And then, you discuss in committee and outside,
ways of approaching this and discuss how you'd like
use cases to be worked out.
And what would look like your a good code once you have it.
And once that discussion is going on, sort of proposal
firms up with more precise syntax, more work on edge cases,
And I find that one of the problems with the current
Committee is that people want finished proposals prepared,
put forward with exact semantics, except syntax,
and endless precise wording.
And we end up talking about technical details rather than
what I consider fundamental language design problems,
which is basically what's the problem
and what's the fundamental way of dealing with it?
And we spent endless time discussing technical details
before we've agreed if and what the problem is.
- So do you believe, in general, the proposals
that are coming to the Committee are trying to hard
to have a full solution?
It might be better proposals if they worked more on
just defining use cases, defining edge cases, and giving
much less thought to what the wording should be,
and that kind of thing?
- I think so, yes.
I think that the Committee should be more collaborative
in developing solutions.
I think that people come in with a proposal,
and they defend it, as oppose to bring a proposal
and see how it works out and then jointly work towards
I think there are too much defensiveness, too many demands
of perfection before the time.
- I think I have a pretty decent follow up to this.
During the C++ whole extended standardization, there was
this idea of having a no except auto facility,
we didn't get concerns at the time, I brought it back
early in the C++ 14 standardization phase, the Beyon asked,
who is this for and where do you need it?
My response for a micro event or a perspective
was that, "Oh let me count.
"I need it in five places."
He asked, "Do you really need it?"
I said, "No."
He asked, "Is it going to be a maintenance burden for you
"either way," I said no.
So his follow up was, "What are you going to do next?"
And I said, "I am going to bury this paper
"and not advance it."
- Alright, Izzy, you have a question for us?
- Alright, so, I've actually got a few,
but I'll make them quick.
So two years ago, I sat on that side of the room and said
to the Committee, when are we gonna end up with strict
qualifier, and I was told it's coming.
And, it's been two years, and it's still not here.
So, where is it (chuckles)?
- I think because there's a queue, you should get one
question each, so we can answer that one.
- I talked to your colleague just before we started,
and he said he was going to have a proposal
for the strict qualifier.
So I assume it is coming from there.
The only advice I gave him was, please, please,
cleaning it up a little bit and toning it down,
don't make it just C99 restrict, because that's not enough.
And he said, oh no, of course not.
Which is, one plus sign.
- It seems as if the auditors of that proposal
have been busy with other things.
But you can find those auditors.
Their names are on that paper.
- No alias must go.
This is non-negotiable.
This was Denny Stritches answer to the father of Restrict.
Restrict has come up repeatedly.
And the reason it has failed is that it doesn't fit
in the type system.
It means trust me, it's a form of cost.
And, we have repeatedly decided that this is a very useful
cost in restricted environments where you can sort of trust
this cost, but we don't like trust me in the type system.
And therefore any proposal that proposes Restrict,
is going to have an uphill battle, because some of us
have kept seeing it for almost 30 years,
since Denny Stritches came out stronger against it
than I would have been able to,
and we'll ask how does it fit in the type system,
how does it generalize, how does it interact with types
higher than raw pointers, and why should this be
a core language feature rather than a specialized
high-performance computing feature.
This is a firm prediction,
because I've seen it happen repeatedly.
- Okay, thank you.
- Is that Oden?
- Yeah, hi, I'm Oden.
I work Metal and Bedding,
but I have a very different question.
This is probably mostly for Herb and Louie.
But, I've seen problems with debugability
of a lot of code generators
because they're very common in my field, and also in Dee,
the omixens are pretty impossible to debug.
And people already complain about stepping through my TMP.
Isn't this a problem for meta classes and such
that people are stepping through a code that they
did not write?
- [Audience Member] The mic, give it to him.
- So, I think you're basically outlining, you already
said it was a problem right now with TMP, right?
- Yeah. - Is anything worse than TMP?
If you ask me, you know, I like TMP.
But, most people don't.
And so what I think is, there is an interesting quality
of implementation challenge for compilers to give
us a way to, you know, debug the meta-programs
that we're gonna write, but I think that if we're not
using the type system the way we are today,
they can actually provide us with better ways
of debugging meta programs, so there's nothing worse--
- The question is more to the user who said interface
or whatever, you know, loaded a keyword, or over loaded
key word you're using, and you know, writes a class
the way he thinks about a problem, and then steps through
and sees this terrible template monster
that he does not understand.
- So you mean stepping at run time?
- Yeah, at run time.
Somebody who's writing Hello World, and then steps into--
- Again, I would say this is a quality of implementation,
like your debugger should be free to, you know, basically
jump, you know, through these things without showing them
to you, unless you maybe request it, right?
- So I'll answer in more detail in my talk on Wednesday,
because this is one of the questions about any code
generation style approach.
The short answer, spoiler alert, is what Louie said.
But I'll expand on it a little bit.
The first is, look at what it's replacing.
So one of the tag lines that I thought I came up with,
and then I saw Louie in his meeting C++ keynote last winter,
use the same tagline and I don't know if it's because
we ever talked about it or because we came up with it
independently, is we both want, and I assume you're still
there, we both want more meta programming,
less template programming.
We're doing it already.
We should have a clearer way to write what we're writing
already, and it will be strictly better than what we are
already doing that is undebuggable in the scruitable today.
The second argument is, especially with code generation,
we are already doing that too.
We generation special member functions.
When's the last time you tried to step into a compiler
generator copy constructor?
And nothing happened?
That problem needs to be solved already for the special
Yes if you provide people a way to generate more
of those programmatically, then yes.
But it's a degree not in a kind of a new problem.
And anything that implementations already do well
for the special member functions will directly help
the other generator functions and visa versa.
In both cases, I think the key thing is, as long as we focus
on trying to improve the things people are already doing
with C++, but with great difficulty,
we're on the right path.
And we're certainly not making things worse.
Longer answer to follow, but that's the bare bones
of the idea.
- My suspicion is that before any of this actually
gets approved, or shortly after it gets approved,
there's going to be, by necessity,
a ton of work in two ling.
Because, as sort of Library Lead for a large code base,
code review is sort of important.
And if you've hidden away any significant amount of stuff
in meta classes, I'm gonna need a way to toggle
between views in the code review,
in browsing, in everything.
And at the point that you've built that, it's not that much
harder to rig that into your debugger.
I mean, there's work there clearly, but like, we have
to solve these UI problems for many reasons,
and the end result is going to be well worth it.
- I think is a very important question that you brought up,
anything we do at compart time, which means evaporates
when the code is running, poses challenge.
So Herb points out, correctly, special member functions
how I generate that compart that you cannot see.
Um, however, when it go further than this special member
functions, where it actually generates code, or class,
or that kind of thing, it poses real challenges to tools,
and if the tools are not there, you're going to have
a very miserable representation for facility.
I distantly remember when I started writing templates
back in '94, '95, the use miserable.
The part that worries me, is when we say oh, we knew
about this problem, we had this problem before,
and it is even worse.
And they'll say actually it is worse by adding more.
So epsilon is epsilon but N times epsilon becomes
very maticiapl for big number of N.
So, I'll be very conscious and not oh we already know this
form, so it's not making worse.
No, we are adding to it, so we must be very, very cautious
My friend here, Ville, has recently compiled and has
some experience in that department.
I've very laced myself, and lace is this language
where everything that you have at one time you can link
it to compart time and even if when operator you can
specify, oh is it compart time?
Is it load time?
Is it desecration time?
So you actually have fine grain ways of doing this.
I don't know that the full power of that is actually used
in practice, so there we have proximity to learn
as languages values, what is actually really important?
So, we different with it, set a reflection that,
has to come right?
When we go further, we have to study how much of that
is actually useful important that we need to have
in the language, and we need to bring the two builders,
compartment writers, not just compartment writers,
source code browsing, and these you need to do
at review time, at design time before you even write
the code for review.
It is not trivial challenge.
It is not we already know what it is.
It is really non trivial.
I guess, the last thing I would like to say is, I really
am a big proponent of compart time, conversation.
I was fed up with people writing functions and class
specializations, you know back in '98, we used to write
back in programs.
We had to write the class and then in specializations
and all that, so with Vinne, we introduced conceptual
functions but these just go back to what has been very
successful understood by all programmers.
It is just simple function.
Now, ensure that you have the right condition,
that the compiler does functions at compart time.
And, it is the same structure that programmers
understand very well, right?
Wrong time functions, and you have to make sure
that you don't have that much distinction in what is being
evaluated at compart time or being evaluated at wrong time,
so that if needed you can actually place sufficiently small
conditions to have this function drawn at wrong time
so we can put debugger in, see what's going on.
It going to be, it is exactly the same experience
that you have with gamma function.
And that's some form of engineering, that's not perfect,
we don't have the full power in compart time computation,
but it is a balance between the full abstracts power
of language design and what is particularly necessary
- C++ has some awful reputation for being bright only,
incomprehensible, too complex, expert only.
And there are some major factors for giving this template
meta programming is one of them, the more advanced parts,
Forboost is another one.
I don't know if I have any friends left in the room,
but this is a fact.
And some of us has been working for years on the theme
of simplifying C++ as used by most users.
Make simple things simple, make sure that you can do
the advanced stuff if you have to.
One of the things that got me with template meta programming
was people writing templates, defining types,
to calculate values.
If I want to compute the values for two or ten,
I want to call a function.
We got context functions, it cost a lot of blood
and sweat and tears, mostly Gabby's, and the Committee
was very conservative.
It was deemed useless, impossible to implement,
and a few other things like that.
But I think it takes away half of the complexity
of template programming, which was a template mechanism
being used for things it wasn't meant to be used for,
and it wasn't good for.
Another aspect is that we are having templates
with Compart Time doc typing.
From every other place in the language, we know that
precisely specified interfaces is a great savior
for specifying things correctly, from catching errors early,
from avoiding to write errors in the first place.
Because, we don't have to write against totally arbitrary
things, and my guess is concepts probably done
will take away another half of the problem.
Now, finally we come back to the meta programming
that we're talking about, and I think we need some fairly
simple meta programming, we want to be able to walk through
data structure and generate object maps for it,
to generate serializes for it and things like that.
And, in particular, I want to make sure that if you
do the object maps for X, and I do the serializes for X,
all programs can compose.
If that's not the case, we have dialect generator.
One of the great advantages of C++ is there aren't
too many dialects.
Lisp is more due to form in some sense, fixable in some
sense , and has an implied plural.
You can't collaborate with other people in a language
where everybody has their own dialect.
And so, I think we have to keep improving the language
both in terms of what we can do with it, and especially
in how easy we can to writing using debugging stuff.
I have a colleague in Budapest who has written a really
nice debug for a template programming.
The complexity is beyond belief.
No body should have to learn that.
And so, we need to think about the reputation of C++,
we need to think about how simply we can do simple things.
Really, if I walked Stream IO of X, I should say,
Stream IO open forin, X, closed forin.
That's all I want to say.
And you should be able to write the code for it.
That's basically a simple follow over the elements
We have three proposals for how to do that, last time
I counted, I probably five if you look at the details.
We need to pick one.
And the way we do that, if we do it right in my opinion,
is we pick the important use cases, there is about 4-6.
No more, we do those, we do them well.
And then we see what happens.
What more do we need?
Let's not build, or try to build, the perfect fully
general meta programming system, for starters.
That has never worked very well.
Getting the simple cases working simply and well,
and with low compile time overheads, that kind of strategy
has worked over the years.
And if we don't get it quite right, we have a chance
of fixing it.
If we instead spend twice as long, we have nothing
to gain experience from, and there's so much
we won't be able to fix it once we get it wrong,
which we so will.
Simple or complex, but we're getting it more wrong
with the complex more complete version.
So, my suggestion is work on simplification,
which is good concepts, good context functions,
and then good generator functions basically based
on the idea of iterating or type doing appropriate things
for it. And let's start small and grow it.
- Couldn't agree more.
Something just to hopefully quick comment following
on something you said: keep simple things simple.
So easy to say.
Everybody and their kid brother and their dog gives
lip service about it, and they don't do it, why?
There's at least three major ways to go wrong.
First is not to try.
Not to be aware of keep simple things simple.
Another way to go wrong,
is to try to make complex things simple.
I have seen many proposals in Committee for that.
We have this nice syntax for this case,
well is that the majority, is that the common case?
Well no, but it's the case I like this today.
No, we shouldn't waste the good syntax on complex thing.
So there's actually an art to making simple things simple.
A third way to go wrong is to make them simple to write
but not to maintain.
Which is exactly what we were talking about
and what you were talking about.
How do I debug the code?
How do I know what it does?
How do I do my code reviews on it?
So, the process like everything I'm going to talk about,
except reporting other people's work which is more advanced,
on Wednesday is pure experimentation.
We're trying to solve a problem, we're still defining
the problem, things are going to be mutable.
But here's a direction worth exploring.
Maybe it'll work out, maybe it won't.
But to do the things the Bearne said,
aim at keeping simple things simple,
make sure that you're focusing on the actual simple things
and not just to write but to maintain,
and being example driven.
What are the use cases?
What are the things we want to say,
and how do we want to say them simply?
If we keep that mindset in mind,
it will help make all of the proposals so much better.
- And I would like it for 20.
- Wait, wait, like what for 20?
- The simple version of this basically my loophole,
- The C++ simple complex - function (muttering)
- Version. (muttering)
- As in a very small feature.
- Yeah, the reflection thing, I hope to get all our concepts
and conspects was almost there.
But basically I hope all of this could be available soon,
meaning in 20, meaning we have to get things running
and tested out over the next two years.
I don't want to go for the super, general perfection,
in 2030 or something scary like that.
- Yeah, so I'll try to make this really quick.
Sorry for all you people getting tired waiting.
So, about the debugability of template meta programming
and meta classes in particular, I've had the same criticism
leveled at my ranges work about range pipelines
and the debugability thereof.
And I think it's far more general than a ranges
or a template meta programming,
it's really about abstraction.
And if you are used to operating at a certain level
of abstraction and someone comes along with a higher level
abstraction, a better abstraction, it's natural to feel
resistance because I'm not used to operating at that level
of abstraction, that's not how I think about things.
I don't know how to debug that, I can't reason about that.
Or I'm gonna have to compile it in my head down
to the lower level code just to understand what's going on.
But, we do that all the time.
We don't think about how virtual functions are implemented.
Right? Well, some people do. (laughter)
The important thing to ask about an abstraction is,
is it a good abstraction, can I write more code,
more efficiently with fewer bugs with this abstraction?
And then, can I learn to think in terms of that abstraction
instead of the lower level details?
And then maybe you find you're actually spending less time
debugging because you're writing fewer bugs.
- I will strongly agree with you, but I think Bearnne's
points are also good, everything you said,
but the abstractions have to be usable.
Not just write only, so we have to make sure of that.
And for them to make sense in this language,
they had better hue to C++ pillar of zero overhead
abstraction, zero overhead principle, machine near,
I can always take an open the hood and take control.
As long as you do those things, then it's C++.
Otherwise, we're just posing a feature that belongs
in some other language.
- Alright, thank you!
- Let's, Cole!
- [Cole] Can I have the floor this day?
- [Announcer] Set down, yeah.
- [Cole] His lying, he was there live performing.
- [Announcer] Ah, okay.
- [Cole] So, first of all, I'd like to talk a little
bit about Respect, and then I'll get in my actual motion.
Which is like the whole no alias thing?
That feels like that thing where you're making the complex
case simple, at the expense of the simple case.
Which is, you know, I just have two pointers,
but I don't want to alias.
And their parameters.
I don't care about all this stuff.
I just want them to not alias.
Which is why I like Respect, and why C Restrict is terrible.
Yeah, and so the question I actually have is about
non-type Template Parameters.
First of all, that's the worst name ever.
It should just be called Value Parameters, because you also
have Template Template Parameters which are also not types,
but like, they're not non-type Template Parameters.
So I'm gonna call them Value Parameters.
I would really love Value Parameters, uh,
Value Template Parameters of non-integer, or integral type.
I would love like, literal type template value parameters.
When can I have that?
- Well, we'd assign them, and you should just ask
for them louder, because some of us really cannot tell
the difference between a user-defined type,
and a build-in time.
- [Nicole] Right? That's what I'm saying!
- Yeah, so, (laughter)
and actually, there have been several suggestions
in that area, notably by me.
I think there is a paper that somewhere that proves
that something was impossible.
I didn't have time to go through, but usually when someone
goes through and proves that something is impossible to me,
I (mumbles) I just say politely that I loose trust.
So, um, it is one of the things we want to have,
but right now we have more high levels stuff
that we need to get through, like modules, core routines,
steady refractions, and networking.
But at some point, to make simple things simple,
this is one of those places that because everywhere else
we don't see dissection between it and complex of double.
Except example, but type perspective, basically the same
thing and you should be able to use your template that way.
We're in some progress there, but yeah. It will come.
- I think you have to demonstrate that there are some
real use cases, and it should be on my top 20 list
Because I think it's obvious your right, but is it important
enough to spend the time on it.
- So, about when you can have it?
First you need to solve a bunch of obstacles.
You want to have a non-type template parameter
of a user-defined type, so the question becomes whether you
want that type to have a user-defined equality operator,
and where is that operator defined, and how do you avoid
all the other problems?
These are the things keeping that facility sort of, back.
We haven't been able to find reasonable answers
to those questions.
- Well, and Louie has it.
- Can I add something?
It is not that we have not found a reasonable answer
to those, is it is that we as a Committee have been able
to agree on a solution, which is very different.
- If, if, if, if... (laughter)
If we agree that the problem needed to be solved,
we would solve the technical problems.
The technical problems are not the hardest.
- Well, this one is kind of hard,
but I think there's a solution, especially if we get
compodre generated comparison operators, we could say
that basically any type that is conceptually friendly
and has the compodre generated equality operators,
you know, we're kind of able to link them.
And, is Jeff Snider in the room?
And so, how's that proposal going? No pressure.
- [Jeff] Have it ready by Albuquerque.
- Albuquerque? Okay, so we have some, it's baking.
- This might be a good example, also, of what Bearne
cautioned against, and what Gabby cautioned against,
jumping to a solution.
So start with, I would love to start with the use cases.
What are the things we're trying to do, and then we can
evaluate how common they are and so forth.
I have seen at least a few examples, of people who wanted
such a feature, a general way to have non-type Template
Parameters in a template, sorry, just pulling the chain
there. - It's a bad thing
you can use it! - For the purpose,
for the purpose of computing something, because they want
to use template meta programming.
Give them something completely different such as an actual
compile time function, they might find that that expresses
what they want even more directly and the use case
goes away, and is better solved
by a completely different approach.
And that's why it's so important to start with the use case,
a problem to be solved, how common is it, what's the code
I want to write ideally, and think outside the box,
and brainstorm early on before narrowing in on one
particular solution; because, maybe in this case
you actually don't want that feature.
Maybe what you really want is Compile Time Functions
and Louie and friends will help you get those.
I just signed you up for work by the way.
- I know, so I do think though that even if we get proper
compiling programming, there is a use case for that.
I don't want to get too technical, but the problem is
when you pass a context per object to a function
from within the function, you've lost the fact
that it is a constant expression.
Because it is just an argument, you don't know,
we don't have contacts per function parameters basically.
That's kind of the problem that this is solving.
And so, even if we get like super fancy extender vectors,
extender string, and constant expressions, which we're
working on, we still don't, we still don't have a way
to propagate the constant expression through
a function called Boundary.
And so this is exactly what this gives us.
- And the important thing with that, is that you can have
the return type depend on the, like, I want,
simplified dependent types in C++.
And I only really get that when I have integral types.
- So, personally I think it's a valuable feature.
There are some technical challenges to be faced.
But, we're kind of working on that, and we'll see
what the Committee thinks about that.
- Clearly, this is not my evening to make lots of friends
by making promises.
What is the use case?
The answer that I can write more elegant template
meta programming is not an answer I'll accept.
It is what can I do with a template meta programming
that helps users solve real problems using that?
You have to go one step further, and maybe you have it,
but I haven't heard it yet.
- [Audience Member] Rust style format strengths
are what I want.
As like, compile time checked, format strings.
- Now we're getting real.
- [Audience Member] Say that again.
Sorry I didn't hear that.
- I said, now we're getting real.
- [Audience Member] Yeah, that is what I want.
I want string view template parameter.
- There are other ways to do that.
- [Audience Member] So what I'm doing,
- I'm not gonna talk about it.
But, there are other ways to do it.
- [Audience Member] So, decal type lamda expressions
work because you can create a struct, or class,
inside a lamda expression, and then you can decal type
return type of that lamda, and so you create an anonymous
struct type that has an operator open prime close perend,
that returns the value of the string as a constextper.
- How many years of computer science does it take
to get that right?
(laughter) - A lot.
- You're not computer science. - This is known as a problem.
- You see why I am pushing back for use cases
that a majority of users can use.
Before I push it up in my Top 20 of things where we
should spend a lot of effort on.
You have some work to do there.
I'm not hostile, I understand what you are saying.
I understand the type algebra, I'm pretty sure I know
how to implement it, but that's not the problem.
- What he said.
I love the compiled time format strings. Kudos.
Run with that.
The rest of it sounds like one of the pitfalls I just
described a few minutes ago from keep simple things,
make simple things simple.
One of the ways to go wrong was try to make complicated
I worry this might be that.
- Also, a lot of the thoughts on format strings are informed
from C format strings, like, R Args, things, where it was
necessary to have a user-specified description
of what type it was.
This is a language about types.
The compiler already knows all of those things.
We have no like, there's clearly room for better
technology here, we should not be trying to mimic
the 70's style design, we should just do something better.
There's things in the works all over the place.
- [Host] Alright, so let's take a question from this side.
- [Questioner] Hi, so I have a drastically different
question, when you have a large project that you're trying
to propose to the Committee, something on the scale
of years, modules, concepts, all these other things,
how do you maintain momentum through all these years?
And actually make the project a reality and standard?
- First you try not to loose it, which is very difficult.
You keep making the cases.
So, we talked earlier about the use cases, compelling,
that we have had with concepts, we explain what the problems
were you know, what the risk of running into them?
It's really important for the Committee to get something
like that into their language.
For modules you get similar problems, right?
Everyone is suffering from lack of good hygienes, macros
getting into the system, you don't have good sense
of what you're templates codes made when you ship them,
build time, most of our code these days live in the headers,
which is a problem.
So, you get to explain this to the community
what the problem is first define the problem.
And patiently work through the possible solutions,
and eventually try to cover to replace where you say
let's try this to see if we had a good solution for these
problems that we have.
But, I guess the most important thing
is try not to loose it, and hand it over to Yannie.
- I didn't hear everything
because I was thinking of something else.
So if I repeat you, apologies.
What I was thinking about was, sort of practically,
what can keep me working on a problem for 20 years?
Which is definitely clearly related.
And I think first of all, it's individual.
What applies to me may or may not apply to others.
What applies to others sometimes applies to me,
but not always.
I've seen people motivated in different ways.
None of the motivation comes from the Standards Committee.
The Standards Committee feels like a huge barrier
from getting your great ideas that will solve
all the problems out into the real world.
And in that, it does a rather important service,
because your ideas aren't as great as you thought they were.
What keeps me going is the applications.
And I see people doing really important interesting stuff
that I like.
I mean, it may be a space probe, it may be the breaks
on your car, that is your screw up you die, it may be
large distributed systems, network systems, and such.
And I look at those problems,
and I think wow this is important,
people's lives and livelihoods depend on it.
And boy, it's pug ugly. We can do it better.
And so, I look at problems starting from what are people
doing out in the real world, meaning things and people
and such, not inside it.
And then I'll look at the code about how they do it,
and I wonder how can it be done easier,
how can it be done more economically,
how can it be done faster?
How could it be done more reliably if reliability matters?
And these things often matter.
And from there,
I go to what I said of kind of candid improvements.
It could be a library, it could be a language feature,
it could be something that could be standardized,
or it could be specialized.
But I keep coming back to what does this actually
do for people out there in the non-computing world?
And I keep thinking that whenever I find the solution,
computer science is a really powerful tool.
We know how to do most things if we decide to them.
I can read academic papers, I can see the experiments
with our languages, I can see the libraries used.
I don't worry too much about whether I can do it.
I worry about whether I have the right problem,
and once I decide that I have the right problem,
it hurts people when it's not there.
And then I start working on a right solution,
and I try to talk to people who know more about it than me.
I try to talk to people
that can help come up with a solution,
sometimes I compromise too much.
Sometimes I compromise too little,
but we have to find a solution that helps.
And that's what keeps me going.
Arguing about a particular about where to stick a comma,
and keep me excited for at least a week.
Because while that's anarchy right, we can argue about those
things for at least a week.
But it doesn't keep me going for years.
For that, you need some really fundamental problem
that would make a fundamental difference.
Currently, the ones we're looking at are concepts,
some are concurrency parallels things, some conversation
of live pressings, the modularity to clean up your code,
and the static reflection things that allows us
to compensate from the problems of not having other forms
And these things have been keeping me going
for a longish time, concepts definitely since the late 80's.
So if I'm impatient, that's one reason.
- So I started my range library four years ago
as a weekend hat.
And what's kept me going is that, well, two things really.
One external and one internal.
The external thing is the feedback that I've gotten
from its users, and it's been overwhelmingly positive.
What keeps me going is that every once in awhile,
I actually get a piece of fan mail.
Someone says dude your range library helped me do X, Y, or Z
and it's really terrific.
And coming to conferences like this and meeting people
who know my stuff and use my stuff.
And have encouraged me over the past four years to continue
with the standardization of the library.
And then the other thing that keeps me going
is more internal.
I might surf around Facebook's code base,
and think to myself oh my God.
Or, I would look at code on Get Hub or people's solutions
to problems and I think there's just too much complexity
And so what motivates me, is my intense need to hack
at the route of software complexity.
I can't not do something about it.
- We have the project editors of two of the long running
projects you've talked about, Core Routines and Concepts
on stage, I'd love to hear from Gore and or Andrew.
- Bane avoidance.
Yeah, so people are most motivated when they are trying
to address the personal pain.
Before Julian's imposteum, I was writing the same code
for 15 years in the Oas Division, so it's a big personal
pain to write the same code.
So I kind of want help.
- So you considered the prose as of standard
as in Core Routines a lesser pain than in not having them.
- Possibly joining C++ team was the pain avoidance.
- [Another Interviewee] We'd love to have you.
- So, I having worked on Concepts for six years,
seven years, it always helps keep you focused when you feel
like you're working on something that's going to improve
somebody else's job or life later on.
That's certainly one thing that keeps
you going on a project.
Positive feedback from users is great.
Bug report maybe less so.
Although they are a good measure of users.
So if you actually get bug reports that means you have users
and therefore your work is at some level visible.
These things also kind of help you keep going.
But, Gabby's actually pretty right on this.
Try not to go insane, is that what you said? Yeah.
Especially through Committee, it can be a soul grinding
task to push a large language feature through
the center's Committee.
You will loose sleep over it.
- Thank you. Alright, Thank you very much guys.
I want to take a question from Izzy, but we are now
going to introduce the new 2+2 rule again.
Two people respond, no more than two sentences.
So think about your responses very carefully.
Izzy, what's your question.
- [Izzy] Okay, that sucks because I was gonna ask
Abby about modules.
So, I've been looking at them excessively, and one
of the things I've noticed is that with the current way
that both Clang and Visual Studio handle them is that if
I have a module B, and module A, A imports B,
and I try to compile module A first and B hasn't been built,
then the compiler errors out because the module interface
isn't there, how is this solved without turning the compiler
into a built system?
(laughter) - Two sentences.
- We can do all short sentences is ridiculous.
- [Questioner] A lot of comments in this sentence.
Make it a run on sentence, deep breath.
- Yes. (chuckle)
This is a problem for two vanders, it is not a problem
in language specification.
I am also two vander, and the way we solve this is also
to get your bill system be module aware.
So that you actually have a compliment, you don't actually
bring the bills into the compartment.
- [Host] That was two sentences.
- Okay, thank you.
- And such a friendly operation.
- [Questioner] Yeah, so my real question what exactly
determines what can be (whispering)
added to the language (whispering)
and not an outsight.
What I see is two conflicting examples.
So back in the 90's there's a proposal to add the keyword
inherited to the language, so you could call your super
classes as implementation of a function from subclasses
of limitation and the answer was this doesn't provide
something new, you can just simply type div your super
class to be inherited all the way down and you've already
got the feature.
So why do we need the compeller to do it?
More recently though, it's counter example, is we
introduced the keywords and, or, not, and those seem
definitely something that the language could already do.
If nothing else, you could just use pound define to do it.
So, just trying to get a better feel, for what makes it
in and what doesn't.
- Two sentences is not enough to answer this question.
- [Host] That's one.
- Navigating large class hierarchies is not at the top
of my priority list.
- I could be wrong, but weren't the and, or, not, aliases
already in C?
I thought they were at least in the C++ pre-processor
since before the inherit keyword, but then I could be wrong
on my history, they've been there a long, long time.
- Been micros in C in their keywords and C 90 dates.
(no microphone on audience member speaking)
- Alright, I think we wanna come back over here.
- [Questioner] I'll try to format this for remedy.
Should C++ have an explicit way of declaring
an uninitialized variable, so that we can get rid
of doing it any other way.
(laughter) Thank you.
You should initialize your variables.
- [Questioner] Thank you.
- [No Mic Audience Member] No follow up.
- [Host] Go ahead.
- [No Mic Committee Person] Oh, wait.
Think about our paper.
- [Host] Oh, leave us hanging!
What a second sentence.
- That was two. You can talk about it later.
- Okay. Yeah.
- [Questioner] Speaking about real world use cases,
there is one use case which everybody in this room
And, the way it's currently implemented in C++, aid
it at least some page.
I'm speaking about formatting in aisle stream
using overload chevrons, chevron operator.
The question is, how sacred is this concept is
for the Committee, and do we have a chance to have
something more usable and more aidable than over the shade
of paraders for my team, Inasaput, out there
as 30 years of where each and every book of C++ uses
a shift operator something, can we finally have something
more usable and relatable for real note.
- My compiler people, and my optimzer people,
and everybody else wants to get off of those.
However, I can't speak for the Committee.
- Everything is possible if you have a well written
proposal with good rationale.
- The IO string solution is an atious solution,
it is type safe and extensible.
What a lot of people want is the 70's solution which is
type unsafe and un-extensible
We have to do better than both to make any progress.
- [Questioner] I believe there is an active proposal,
or soon will be for FFT, I don't know it's status,
but I consider it better.
That wasn't my question though. My question is,
what's so hard about standardizing atomic shared putter.
- We're doing it, it's going through library wording
review, and it's expected to come up for pled revote
into C++ 20, it, were, weren't you the same person
who was just here?
You're now later in your own queue.
It's expected (laughter)
It is very likely to be part of C++ 20 in the next
meeting or two unless something comes up.
It was published as part of the concurrency TS first,
so it seems to be on tract.
- [Host] So the answer was nothing? One word?
- [No Mic Audience Member] It's a very long one word.
For a very large value of one.
- But also it comes back to motivating use cases.
It required convincing from people who were skeptical
about the use cases.
- Okay, let him go first, alright.
- What the hell is a monad.
- No, no, no, no, no.
- What is a monad is the question.
- Monad, oh geese.
- And, this is the wrong Committee.
- It's warm fuzzy thing. - We do have duel positions.
- It's warm fuzzy thing.
- Warm fuzzy thing, yeah.
- It's a monoid in the in the category of endofunctors.
(laughter and clapping) - Now I have to remember that.
- One sentence.
- [Host] Very good.
- [Questioner] I watched a video from the grola Committee,
I believe it was last term or maybe the year before.
It was pertaining to my field of, you know, bear metal
stuff and why everybody uses C, and the answer coming
from the Committee was it's a marketing problem.
And, I agree with you on core language, like, you know,
in our build system, there are maybe 20 compiler flags
turning off absolutely everything we can turn off,
and then at that point, we are more efficient than C.
So there's no problem there in my mind.
But when it comes to libraries, do you still it as only
a marketing problem, or have you used like inter service
routines that interrupt a thread in use it stack?
And the implications of locks in that context and stuff?
- Well, in C+, in Windows internal, people use C++
but not the library.
- [Questioner] Yes, yes.
- But at these G14 group, which right now is looking
into those things and trying to address those
bare metal people.
- It's a monitoring problem because C doesn't have
anything better either.
- [Questioner] I agree.
- And, if you look at this from a library, you know,
the list here pride for example, most of the algorithms
are just fine with, you know, bare metal.
They don't recur any extra run time, or any of those.
So I've seen them used C practice, so I agree,
it's marketing and education problem.
- [Questioner] Could I tie this back into Eric Neebler's
response to my last question about level of abstraction?
Because, there is a certain level of trust that the person
who wrote that level of abstraction in code and language
that I cannot review because it's in a langu--
You know, a part of the language that I do not speak,
that he was thinking about my problem,
and that the guarantees he's making for, you know,
desktop development will also hold in another context.
- Yeah, I can speak to that, I've seen people very fearful
of using sup strokes because they say oh it is the XTL
stuff, and they were using bubble surfs, and I had to sit
down with them and go through the code, and convince
them that this if future types sup strokes.
I give the first I go in the second admin, it'll go
much faster than the bubble surfs you just wrote yourself
because you couldn't trust this other library
because it has higher abstraction level.
This is from real world.
- [Host] I think Titus wanted to be the next responder.
- You have to know how much to trust your librarians.
They have to be clear about what they're actually
providing and what they aren't.
See my talk tomorrow.
(laughter) - Okay.
- There's plenty of room for improvement in order
to make the library more useful for the use cases
that you care about.
But luckily there are people working on that problem.
- Okay, so now we are at 15 minutes.
So we're gonna stop the rule of two and two, and we're
gonna go on the rule of five.
You have five words.
- Oh boy. (laughter)
- [Questioner] Alright well mine was gonna be difficult
to answer in two sentences, and also kind of a
repeat of Owen's that I know we've talked about this before.
I didn't know he was going to ask that one.
But it's kind of shaded into this one, which is,
in C++ we have a very well, sort of, core languagy
way of expressing certain properties about behavior.
Certain things like this function doesn't throw,
and therefore things that call it don't throw,
and that no except goes all the way up constect per ness
can kind of be propagated now, triviality can be
propagated, but certain other things, pureness,
non memory allocation, non touching globals touching
only thread local storage, not taking new text logs,
not doing this guy up, many, many different things.
Kind of what Owen was saying, right?
The high level code has certain things it wants to know
about the low level code in the way that's gonna use it.
You said some people are working on this.
Who is working on this, or what progress is being made,
in not necessarily tax atomizing and categorizing
the different kinds of behaviors, 'cause they're infinite,
but allowing the high level code to ask these questions
to the low level code and make these guarantees?
Five words or less.
- Try solving it with contracts.
- Can you say that,
I didn't hear you. - And I simply don't
accept the five word (laughter)
answering things because (laughter)
you can't give a really, decent, thoughtful answer to that.
And it deserves an answer.
First of all, we should not litter the language
with a keyword and a prophesy for everything anybody
could possible want.
Language says what is plausible and what it means.
It doesn't say what it should do.
In particular, it does not say what you should do
in a particular sub field.
I write a lot of code where calling Mayloc is a disaster,
it must not happen.
That should not be a library, a language feature.
It should be a guidelines feature.
And what we need is a not so call guideline for say,
Bear Metal programming, for low-latency programming,
for programming where you are not allowed fraternization
and things like that.
- [Question] Well, I think my problem with that,
in is library codes such as the STL where for example,
you have to know that sort is perfectly safe to use
and instead place merge is not safe to use in exactly
your use case, but they don't expose that in any way
in the type system.
Is it possible to do that?
- Contracts, concepts, guidelines.
- Save 'em for next time. Alright, Cole.
- [Cole] So first of all, the keyword like the and, or,
not keywords, I looked it up, it comes from C95,
which was kind of the internationalization of the C89
standard for international keyboards that may not
have those specific characters on them.
- It's not true, I did it before that.
- [Cole] That was the reasoning
that the destandard gives, anyways.
So, what was my question, something.
I've completely forgotten.
- No it doesn't. C never credits us.
You can hear that comment.
When C takes something, they never credit us.
And they always adopt it incompatible fashion.
- Yeah! - Okay, okay.
- Slash, slash, maybe if anybody can understand
that section of the standards.
- I'm sorry. (laughter)
- [Questioner] This is sort of a bit later, and it may be
more interesting to do in five words except Herb who gets
seven because he saved two the other time.
All of you guys, when you're all introduced to all of you
as being up here for like, being associated with a specific
thing you do, or a specific thing you're working on.
So, it'd be really great, if in five words or less,
people could talk about some, like, describe like how
that idea came around.
Like, your Eureka moment, or how you got associated
with the things that you're now working on.
Except for Herb he gets seven.
- [Host] This may be a CBB cast thing, rather than--
- Little more important than now simplicity.
- To boldly go, this will not work.
- Eh, go ahead.
- Boost range plus boost iterator equals adaptors.
- Herb wouldn't let me decline.
- Oh, so many things I could say about Concepts.
But I will decline.
- Write state-machines as imperative code.
- Five words is also about fun.
- Boost impale, no, boost-impale meta-programming
lots of pain.
- [Host] Alright, Cole.
- [Cole] Alright, so.
Back to the thing I was talking about before.
I would really like, (laughter)
- We may have to put a limit on the questioner as well!
- [Cole] I would like decal-type, shoot.
I want decal-type lamdda expressions.
When decal-type lambda expressions.
- I'm working, I'm working on the like 5th iteration
of the wording.
It's just, it's been true eatagully.
It's just about getting the work done.
Actually, if there was core people in the room,
please review the paper, it doesn't make that list,
because I want to be done in Albuquerque hopefully.
- [Questioner] So, what happened to unified call syntax,
and how to resurrect it?
- Got cured when people got more concerned with the past
than the future.
Maybe it'll come back.
This is not completely unified opinion by everybody.
- Makes librarians jobs hard.
- So let me try to provide a less inflammatory response
than we already did.
Why? Because it's my job.
So, there are major concerns about silent changes
to what your code means.
- [Questioner] Have you thought about extension methods?
- Let me give you a general answer, and I'm not going
to stick to five words.
Because it's an instructive example.
The concern is, you're bouncing compatibilities,
so not changing the meaning of old code,
and also future usability.
If we don't change the meaning of old code, we can't just
make member non-member be equal.
Because that would change the meaning of this call site
to all code, could suddenly call a better match
that's the other thing, right?
Therefore, and this is the key part.
You have to have a fall back.
Anytime you have compatibility, it involves a fall back
in our language feature.
So you're falling back.
That gives you the backward compatibility.
Anytime you have a fall back, it means you can in the future
write code that compiles fine today, but if somebody
writes a better match that hits the non fall back case,
could change the meaning of that future code.
Now this is code that does not exist today.
But this is where Titus and others are concerned
that yes, but now I'm writing code that doesn't exist
today, which I could make change meaning.
Now, some people feel well, they'll get over it.
It's just like name hiding, it's exactly the same thing
with name hiding in class heierchy.
And some people are more worried that they don't want
more of that in the language, or they're concerned
about it spreading further.
But this is a fundamental tension.
It's not just about unified call center syntax.
Backward compatibility, you often resort to a fall back
to maintain backward compatibility and then it creates
a hiding situation where you can hide something
by a new code that didn't exist before in the new cases.
Think that through, with an example or two, and you'll see
what I mean, but it's a very general problem.
Not just, it's any compatible extensions.
- [Questioner] Aren't we trying to hard?
We should keep simple things simple, and there are languages
that have solved this problem, and we should learn
from them, and there are multiple--
- Ask the Python folks how they like their bifurcation.
- [Questioner] Just look at C Sharp, and other languages
that have extension methods, it works.
- C Sharp hasn't been in existence for multiple decades.
Nor does it have existing code basis of multiple billions
of lots of code.
It's a different problem from their perspective.
- I mean, we solved the compatibility problem.
It is the question of whether at another war load
and whether that is acceptable.
- Also, it's very important to learn from other languages,
so the C Sharp experience was cited in Bearnes
and my papers, we were the main authors of the unified
function syntax proposal.
But it's also important to understand
where they're different.
C Sharp doesn't have free functions.
It's a different language.
They're experience may inform what we do, or it may not.
So it's important to keep eyes very wide open.
And see what are the valid learnings,
and what are the invalid learnings, the McGuffins
that can actually lead you astray.
- Thank you. (laughter)
- Our meta classes scheduled to be discussed
by the Committee?
If so, when? Otherwise, why not?
- There was an initial presentation for the very first time
just two months ago.
Very early days, this is going to go on for years
whether it pans out or not.
So, some said is this in C++ 20?
Oh my goodness, we won't know if it works until then.
So this is very long lead and experimental.
The things in this area that will come sooner
are refluxion, compel time programming.
- Yeah, we're going to keep pushing smaller parts
of that through, SG 7 I think.
- Yes. SG7. Slowly.
Very, very slowly.
- Is that auto?
- I can't do it!
- Hi, so forgetting Richard's statement is zan van heiber
inherited from C, so why do we still have it in C++?
Why it is still undefined behavior if you forget
a return statement in the function?
- You're not initializing the return of a variable,
or term object.
- Yeah, but you could define it as do not compart.
Like, the comparts are pretty good at finding those things
and ishings worrying.
- Secular is something that the Committee takes
When we did Concepts, one thing we made sure was that
if you run it undefined behavior, it will be detected.
Compart is required to detect it and report it back to you.
So the question is whether we will have enough experience
with that, and fit affordable and move that part time
guarantee to run time, right?
So, it's always a matter of getting the experience,
getting some familiarity, to get into new territory.
- What are your thoughts
on a safe chain dereference operator?
A safe chain dereference operator, where you dereference
if it's null, it returns null.
- That's an interesting idea, but I think beyond
is going to call that swift anyway.
I think it's potentially so useful an idea, that it would
be worth proposing it and discussing it.
Whether that discussion will lead to a actually language
extension is very different matter.
- Wow, we're there.
And we, I guess the rule, oh--
- We do that with delete.
- Five words. (laughter)
- Alright, um...
I think, I think it's been very educational.
One of the things that we found is that some of the members
can count to two or to five.
I want to thank the Committee (clapping)
for representing them tonight. (clapping)
So we'll see you all again tomorrow.
I hope you're having a great time.
- [Audience] Thank you! (clapping)