- Good evening, I hope everyone's having a good conference so far. - [Everyone] Woohoo! (clapping) - Alright. Very Good.
(clapping) Very good. 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. - 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. (laughter) 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 in Toronto. - Well, trust me, loosing
weight is not an easy, okay. (laughter) 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, might serve. I also do some tweaks
to make Lamdas better, like template Lamdas. And stuff like that. (clapping) - 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... (clapping) Super excited about that,
which means that I can stop having to process book
reports on the Rangous Technical Specification. 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 Technical Specification. I did last summer's meeting
in Toronto, it was sent out as a PDTS ballot,
PDTS means Proposed Draft Technical Specification. 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. (giggles) (laughter) - Okay, I'm Piano. (laughter) 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. (laughter) 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. (chuckle) 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. (clapping) 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 awesome. - 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. (laughter) 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? (laughter) - From my perspective, I
think it' the wrong question. - Okay! - 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 refinement. 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 a solution. 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." (clapping) - 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)? And then-- - 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. - Okay. - 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. (chuckles) - 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? (laughter) - [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. No, seriously. 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 member functions. 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 about that. 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 and useful. - 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 of structure. 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. (chuckles) - 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 of features. 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. (laughter) 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. (laughter) - [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 things simple. 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. (laughter) 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? Speed matters. 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. (laughter) 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 of reflection. 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 in software. 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. (laughter) 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. (laughter) (clapping) - Possibly joining C++ team
was the pain avoidance. - Andrew. - [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. (laughter) 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. (laughter)
(clapping) 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. I'm done. - [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. (laughter) - Navigating large class
hierarchies is not at the top of my priority list. (muttering) - 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) (giggles) - 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. - No. (laughter)
Thank you. You should initialize your variables. Two sentences. (laughter) - [Questioner] Thank you. - [No Mic Audience Member] No follow up. - [Host] Go ahead. - [No Mic Committee Person] Oh, wait. - Maybe. (laughter) 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 uses regularly. 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. (laughter) (clapping) - 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. (laughter) (clapping) - 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. (laughter) 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. (laughter) - No, no, no, no, no. - What is a monad is the question. - Monad, oh geese. - And, this is the wrong Committee. (laughter) - 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. (laughter) - 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. (laughter) - [Cole] That was the reasoning that the destandard gives, anyways. So, what was my question, something. (laughter) 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. (laughter) - Yeah!
- Okay, okay. (laughter) - 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. (laughter) - To boldly go, this will not work. (laughter) - Eh, go ahead. - Boost range plus boost
iterator equals adaptors. (laughter) - Herb wouldn't let me decline. (laughter)
(clapping) - Oh, so many things I
could say about Concepts. But I will decline. - Write state-machines as imperative code. (cheering)
(clapping) - 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. (laughter) 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. (clapping) - [Questioner] So, what
happened to unified call syntax, and how to resurrect it? (laughter) - 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. (laughter) 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. (laughter) - Yes. SG7. Slowly. Very, very slowly. - Is that auto? (laughter) - 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 very seriously. 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. (chuckles) 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. (laughter) - 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. (laughter) 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)
I realize there's a time crunch, but can we not request 2-sentence/5-word answer limits to questions? I feel like it wastes time (with people spending time thinking about/counting out answers, then awkward laughter) and we miss out on potentially more interesting and thoughtful answers to otherwise interesting questions.
I love these segments, I just also find those parts so cringeworthy.
Consistently one of my favorites parts of CppCon. Thanks to /u/JonKalb and the panelists for keeping this going. (And thanks to Jon and the other volunteers for the conference as a whole!)
Pretty long winded answers.