Re: C++17 is feature complete
Some updates:
https://www.reddit.com/r/cpp/comments/4rj7us/trip_report_c_standards_meeting_in_oulu_june_2016/
Especially interesting are the mentions of 'accepted'
features/proposals for 'C++20', including:
- `operator.` (opDispatch) which /might/ even make it into C++17
given push by some international body; also includes some facets
of `alias this` as it's hoped to be a core part of some of the
reflection proposals [1]
- designated initializers (from C) (D's static initializers but
tied to struct names and usable anywhere `MyStruct{ field2: 0,
field1: 'a' }`;
and some requiring 'further thought' like:
- discriminated unions (even full-blown pattern matching); [2]
- 'overload sets as function arguments' (basically the delegate
pattern in D for passing a lazily determined member function
pointer (or an untyped closure in general));
- contracts ('expects = in' and 'ensures = out()' but they take
one big boolean expression; a bit more complicated than in D, but
they're adding them in, not taking them out) [3]
- 'parameter packs outside templates' which could go several ways
from being basically native tuples with dedicated syntax, to
almost (? not sure about differences in the proposal's
specification vs behavior in D) the same thing as alias tuples in
D now. [4]
I tried to focus on stuff already in D and stuff people are
asking to add to D and the differences between the languages in
them. I'll stop if it's deemed too off-topic :/
[1] http://wg21.link/p0252
http://wg21.link/p0352
http://wg21.link/p0060
[2] http://wg21.link/p0095r1
[3]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4415.pdf
[4]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html
Re: C++17 is feature complete
On Wednesday, 29 June 2016 at 16:38:07 UTC, Enamex wrote: That's what I said. They're not in the C++17 spec but we won't be waiting for C++Next for them, hopefully. Grafting a meaningful module system on top of a 40 years old language is full of pitfalls and making the wrong choice would be a disaster, so I would not expect to see it production in another 3+ years... But I don't really have performance issues related to include files. It is more of an annoyance, but you can work around it by being careful about what you include and how you structure your files (break frequently shared stuff into separate files). What I do like about where C++ is heading is that they have set up a study group for game programmers and low latency programming (SG14). D should do the same. :-P
Re: C++17 is feature complete
On Tuesday, 28 June 2016 at 19:27:36 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 28 June 2016 at 18:50:25 UTC, Enamex wrote: Also, C++17 is 'getting' Modules and Concepts Lite later in tech specs... that don't even have working drafts according to this [https://isocpp.org/std/status] (but have experimental implementations in Clang and VC++, at least). Modules is not part of C++17, it is on a separate track. Concepts are also not part of C++17. Maybe it would be a good idea to not complain so much about languages you guys don't know much about. I suggest focusing on making D better instead. That's what I said. They're not in the C++17 spec but we won't be waiting for C++Next for them, hopefully. And I complained about nothing; and know little about _any_ language; still so much to learn.
Re: C++17 is feature complete
On Tuesday, 28 June 2016 at 18:50:25 UTC, Enamex wrote: On Monday, 27 June 2016 at 19:47:14 UTC, Ola Fosheim Grøstad wrote: Are you trolling me? Please, no need to. Huh? What exactly are you trying to convey? Also, C++17 is 'getting' Modules and Concepts Lite later in tech specs... that don't even have working drafts according to this [https://isocpp.org/std/status] (but have experimental implementations in Clang and VC++, at least). Modules is not part of C++17, it is on a separate track. Concepts are also not part of C++17. Maybe it would be a good idea to not complain so much about languages you guys don't know much about. I suggest focusing on making D better instead.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 19:47:14 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 19:39:20 UTC, luminousone wrote: OpenCL is for micro threading, not simd. What is your point? Clang++ vector extensions use OpenCL semantics, so you need to look up the OpenCL spec to figure out what it supports. It is not well-documented in the Clang documentation. Are you trolling me? Please, no need to. Also, C++17 is 'getting' Modules and Concepts Lite later in tech specs... that don't even have working drafts according to this [https://isocpp.org/std/status] (but have experimental implementations in Clang and VC++, at least).
Re: C++17 is feature complete
On Monday, 27 June 2016 at 19:39:20 UTC, luminousone wrote: OpenCL is for micro threading, not simd. What is your point? Clang++ vector extensions use OpenCL semantics, so you need to look up the OpenCL spec to figure out what it supports. It is not well-documented in the Clang documentation. Are you trolling me?
Re: C++17 is feature complete
On Monday, 27 June 2016 at 19:34:18 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 19:32:39 UTC, luminousone wrote: Its the nature of being compatible with C, it might not be explicitly stated in the spec, but the only place to put the vtable pointer and stay compatible with C structs is at the end. No... You are making way too many assumptions. By all means believe whatever delusion fits your corner of the universe.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 18:58:25 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 18:23:11 UTC, default0 wrote: Regarding C++ I found this to be a fun read: http://yosefk.com/c++fqa/ :-) A lot of it makes sense... C++ is what happens when you evolve, evolve, evolve and evolve a language from a starting-point that was not a high level language, desperately trying to hone it into high level shoes... Those shoes will never fit perfectly, obviously. It gets even more expansive when you add inn compiler extensions. For instance gcc/clang simd extensions is basically taking in parts of OpenCL into C++. In order to figure out how they work you have to read the OpenCL spec... I only found out today that I can do "simd.even" and "simd.odd" to get even and odd elements from a simd register in Clang... after implementing it manually first. ;-/ OpenCL is for micro threading, not simd. OpenCL allows you to run thousands of instances of the same function in parallel, in either the cpu and/or the gpu. SIMD or single instruction multiple data, is for instruction level parallelism,aka vector add op that adds 4 floats to 4 other floats in a single cpu instruction.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 19:32:39 UTC, luminousone wrote: Its the nature of being compatible with C, it might not be explicitly stated in the spec, but the only place to put the vtable pointer and stay compatible with C structs is at the end. No... You are making way too many assumptions.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 16:48:16 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 16:38:07 UTC, luminousone wrote: easy to implement. In C++ the exact position of the vtable depends on what is in the base most class, it might be 8bytes in, maybe 20, maybe 200, you just don't know, And certainly the runtime can't know. I know what the usual implementation is, but I don't believe it is required by the spec. So it is implementation defined and the runtime most certainly can know if that is part of the requirement. As I said, you don't even need to use a vtable AFAIK. Can show me the section in the spec where it is required? I can't find it. Its the nature of being compatible with C, it might not be explicitly stated in the spec, but the only place to put the vtable pointer and stay compatible with C structs is at the end. You will notice in D you can't inherit from a struct, this isn't merely design choice.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 18:23:11 UTC, default0 wrote: Regarding C++ I found this to be a fun read: http://yosefk.com/c++fqa/ :-) A lot of it makes sense... C++ is what happens when you evolve, evolve, evolve and evolve a language from a starting-point that was not a high level language, desperately trying to hone it into high level shoes... Those shoes will never fit perfectly, obviously. It gets even more expansive when you add inn compiler extensions. For instance gcc/clang simd extensions is basically taking in parts of OpenCL into C++. In order to figure out how they work you have to read the OpenCL spec... I only found out today that I can do "simd.even" and "simd.odd" to get even and odd elements from a simd register in Clang... after implementing it manually first. ;-/
C++17 is feature complete
Regarding C++ I found this to be a fun read: http://yosefk.com/c++fqa/ :-)
Re: C++17 is feature complete
On Monday, 27 June 2016 at 16:38:07 UTC, luminousone wrote: easy to implement. In C++ the exact position of the vtable depends on what is in the base most class, it might be 8bytes in, maybe 20, maybe 200, you just don't know, And certainly the runtime can't know. I know what the usual implementation is, but I don't believe it is required by the spec. So it is implementation defined and the runtime most certainly can know if that is part of the requirement. As I said, you don't even need to use a vtable AFAIK. Can show me the section in the spec where it is required? I can't find it.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 16:10:13 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 June 2016 at 16:03:44 UTC, luminousone wrote:
C++ post pended vtable pointers, Are not implementation
dependent.
I don't know what «post pended vtable pointers» means. Which
section of the C++ spec are you referring to?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
Member name lookup, Virtual functions, some where in their.
When you declare an object,
class a{
int b;
int c;
//** the compiler puts a hidden variable here called the vtable
pointer **//
void **vtble;
virtual void somefunc();
}
All of your virtual functions are referenced from this table; So
that inherited classes will call the correct function based on
the type of said object and the overrides in said object.
C#, D, put the vtable as the very first item in the base most
class, C++ puts this as the last item in the base most class, C#
and D use the first item in the vtable for type information
generated by the compiler at compile time. Because the vtable is
in the same place in ALL objects type reflection is very easy to
implement. In C++ the exact position of the vtable depends on
what is in the base most class, it might be 8bytes in, maybe 20,
maybe 200, you just don't know, And certainly the runtime can't
know.
Granted their are really bloated, slow, and memory chugging ways
around this, such as storing a list of every allocated object in
memory somewhere, and having reflection calls search this using
an objects memory address.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 16:03:44 UTC, luminousone wrote: C++ post pended vtable pointers, Are not implementation dependent. I don't know what «post pended vtable pointers» means. Which section of the C++ spec are you referring to? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
Re: C++17 is feature complete
On Monday, 27 June 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 15:54:16 UTC, luminousone wrote: C++ has post pended vtable pointers on class objects, its unlikely good reflection can ever be added to the language, as the vtable may be in a different place in every object their is no way to access it universally for object type information. Some Compile time type reflection might be possible, But I bet it ends up being flimsy. Huh? IIRC it is implementation defined in C++. There are C++ compilers/tools that provide more extensive reflection, but it is not part of the standard beyond simple typeid reflection. C++ post pended vtable pointers, Are not implementation dependent.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 15:54:16 UTC, luminousone wrote: C++ has post pended vtable pointers on class objects, its unlikely good reflection can ever be added to the language, as the vtable may be in a different place in every object their is no way to access it universally for object type information. Some Compile time type reflection might be possible, But I bet it ends up being flimsy. Huh? IIRC it is implementation defined in C++. There are C++ compilers/tools that provide more extensive reflection, but it is not part of the standard beyond simple typeid reflection.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 06:16:57 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 05:33:24 UTC, luminousone wrote: On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! Now if only they could bring over some of D's superior template syntax, all of the <>'s are so damned ugly, Or type reflection features(is this even possible in c++?). Ugh, D's template syntax is far from superior :-(. What kind of type reflection are you thinking of? C++ has static type traits and some very limited dynamic reflection for classes with virtual functions, but C++ is nowhere near Python's capabilities. C++ does have a special interest group working on reflection: https://root.cern.ch/blog/status-reflection-c D's template syntax is vastly superior to C++... C++ has post pended vtable pointers on class objects, its unlikely good reflection can ever be added to the language, as the vtable may be in a different place in every object their is no way to access it universally for object type information. Some Compile time type reflection might be possible, But I bet it ends up being flimsy.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 15:49:20 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 15:43:03 UTC, luminousone wrote: Modern C++ is a train-wreck, I don't think we should consider D features around the flaws of another language. RAII is the same in C++, but actually better supported in C++ atm. I meant: Issues around RAII are the same in D as in C++.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 15:43:03 UTC, luminousone wrote: Modern C++ is a train-wreck, I don't think we should consider D features around the flaws of another language. RAII is the same in C++, but actually better supported in C++ atm. Luckily we don't have to code with the worry of labyrinth like namespaces so deep and bloated that the language needs a special keyword to let the compiler know that the following blobby mass is a typename. Namespaces tend to be shallow, not deep. "typename" is a syntax compatibility issue, not a namespace issue. I don't think I understand your argument? But if D keeps adding syntactical sugar and many ways of doing the same thing like C++, it will end up in the same bloated spot with no hope of recovery.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 15:16:19 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 June 2016 at 14:57:10 UTC, Patrick Schluter wrote:
I forgot. No it's not more readable, to the contrary. The
issue is that normally { } introduces an indentation, which is
always associated with some kind of branching. Adding an
indentation just for the declaration of a variable is an
inconsistency annoying to read. I had the case several times
in the code I was transforming and it had me each time puzzled
at where the loop or condition was.
I see your point, but I like to keep conditional clean. Usually
the expression is long when I have to check an error code in
C++. I don't think the following is easy on my eyes and it is
not at all clear where the destructor is called:
if ( auto file =
::tool::filesystem::open("/path/to/somewhere/xx"); file !=
nullptr) {
...
} else if(…) {
...
} else {
...
}
I think this is easier to read, and the location for the
destruction is obvious:
{
auto file =
::tool::filesystem::open("/path/to/somewhere/xx");
if ( file != nullptr ) {
...
} else if(…) {
...
} else {
...
}
}
In modern C++ one has to think about introducing scopes to gain
control over where RAII is created and destructed.
Modern C++ is a train-wreck, I don't think we should consider D
features around the flaws of another language.
Luckily we don't have to code with the worry of labyrinth like
namespaces so deep and bloated that the language needs a special
keyword to let the compiler know that the following blobby mass
is a typename.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 14:57:10 UTC, Patrick Schluter wrote:
I forgot. No it's not more readable, to the contrary. The issue
is that normally { } introduces an indentation, which is always
associated with some kind of branching. Adding an indentation
just for the declaration of a variable is an inconsistency
annoying to read. I had the case several times in the code I
was transforming and it had me each time puzzled at where the
loop or condition was.
I see your point, but I like to keep conditional clean. Usually
the expression is long when I have to check an error code in
C++. I don't think the following is easy on my eyes and it is not
at all clear where the destructor is called:
if ( auto file =
::tool::filesystem::open("/path/to/somewhere/xx"); file !=
nullptr) {
...
} else if(…) {
...
} else {
...
}
I think this is easier to read, and the location for the
destruction is obvious:
{
auto file = ::tool::filesystem::open("/path/to/somewhere/xx");
if ( file != nullptr ) {
...
} else if(…) {
...
} else {
...
}
}
In modern C++ one has to think about introducing scopes to gain
control over where RAII is created and destructed.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 14:19:16 UTC, jmh530 wrote:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any
type whatsoever
'template';
Still adding D features, I see!
constexpr if looks a lot like static if to me.
I don't think it is like static if. AFAIK it cannot turn off
member fields and it cannot turn off static_asserts. "if
constexpr" is primarily for preventing instantiation issues, so
it does not introduce a separate compilation stage like in D.
In C++ this will fail to compile:
if constexpr(false){
static_assert(false);
}
Re: C++17 is feature complete
On Monday, 27 June 2016 at 06:52:58 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any
type whatsoever
'template';
Still adding D features, I see!
Imitation is the sincerest form of flattery, so when is
destructuring coming to D?
Also, the `if (init; condition) and switch (init; condition)`
seems like a very nice idea.
It's from Go, I don't see much value in it. You can just wrap
the if in a block:
{
init;
if(condition)…
}
That is usually more readable IMO.
I forgot. No it's not more readable, to the contrary. The issue
is that normally { } introduces an indentation, which is always
associated with some kind of branching. Adding an indentation
just for the declaration of a variable is an inconsistency
annoying to read. I had the case several times in the code I was
transforming and it had me each time puzzled at where the loop or
condition was.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 06:52:58 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any
type whatsoever
'template';
Still adding D features, I see!
Imitation is the sincerest form of flattery, so when is
destructuring coming to D?
Also, the `if (init; condition) and switch (init; condition)`
seems like a very nice idea.
It's from Go, I don't see much value in it. You can just wrap
the if in a block:
{
init;
if(condition)…
}
That is usually more readable IMO.
No, it's the logical conclusion from the for(init; condition;
increment) loop and the declare a variable anywhere feature,
introduced in C++ long time ago.
It's funny that C++ now will introduce it, as I had the same idea
a couple of weeks ago for C. I'm currently in the process of
transforming old legacy C code that had all their variables
declared at the top, to a more modern style, using C99 feature
taken from C++, i.e. vars only declared and initialized when they
are used and using for(initdeclaration;...) style.
It appeared quite rapidly that in a lot of cases the if(init; and
switch(init; would have been nice as it would have brought a lot
of regularity in the code and it allows to limit the scope of a
temporary variable really to the section it is used in without
overloading the code with { and }.
btw: I was first quite skeptical of the gain to be had of that
scope reduction transformation, but after discovering several
serious bugs in our code because of scope errors, I am now
transforming more systematically to that style our 200K lines of
C code.
Re: C++17 is feature complete
On 28/06/2016 2:19 AM, jmh530 wrote: On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! constexpr if looks a lot like static if to me. You're not alone on that one.
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! constexpr if looks a lot like static if to me.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any
type whatsoever
'template';
Still adding D features, I see!
Imitation is the sincerest form of flattery, so when is
destructuring coming to D?
Also, the `if (init; condition) and switch (init; condition)`
seems like a very nice idea.
It's from Go, I don't see much value in it. You can just wrap
the if in a block:
{
init;
if(condition)…
}
That is usually more readable IMO.
Re: C++17 is feature complete
On Monday, 27 June 2016 at 05:33:24 UTC, luminousone wrote: On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! Now if only they could bring over some of D's superior template syntax, all of the <>'s are so damned ugly, Or type reflection features(is this even possible in c++?). Ugh, D's template syntax is far from superior :-(. What kind of type reflection are you thinking of? C++ has static type traits and some very limited dynamic reflection for classes with virtual functions, but C++ is nowhere near Python's capabilities. C++ does have a special interest group working on reflection: https://root.cern.ch/blog/status-reflection-c
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! Now if only they could bring over some of D's superior template syntax, all of the <>'s are so damned ugly, Or type reflection features(is this even possible in c++?).
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! Imitation is the sincerest form of flattery, so when is destructuring coming to D? Also, the `if (init; condition) and switch (init; condition)` seems like a very nice idea.
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! Now cpp has structured bindings although it's a limited version of match. So when will DIP32 and match be taken into consideration in D?
Re: C++17 is feature complete
On 6/26/2016 3:32 PM, Walter Bright wrote: On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see! Reading: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r1.html shows it is something else.
Re: C++17 is feature complete
On 6/26/2016 10:18 AM, Enamex wrote: - template arguments that accept constant values of any type whatsoever 'template'; Still adding D features, I see!
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote: - specified order of evaluation for function calls and any syntax with arguments (including built-in operators on primitive types). But not on the arguments, as that will harm optimization too much. I believe this change was triggered by the lack of transparency in expressions with more complicated "chaining" of function calls/function-objects. So in "expr1(expr2,expr3)" expr1 is evaluated first, but expr2 and expr3 can be evaluated in any order. Right?
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 18:16:32 UTC, Jack Stouffer wrote: Please be excited for modules, coming out three years from now (plus implementation time). It is actually a good thing that they delay modules. It is difficult to get right, but it is on a separate track so it can come before C++Next. The most important parts of C++17 is related to ironing out language quirks and providing library additions: some significant improvements to meta-programming, file system support and C11 support which brings in things like aligned_alloc. There is a significant signal in reserving the namespace "std"+digits, meaning there will be a major standard library update in C++Next (related to "ranges").
Re: C++17 is feature complete
On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote: https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/ Added stuff like: - a very limited destructuring syntax (structured bindings) (use case is for tuples; but likely to use a new reserved function name for general struct destructuring (like 'get<>()' or something); - template arguments that accept constant values of any type whatsoever 'template'; - 'constexpr if'; - specified order of evaluation for function calls and any syntax with arguments (including built-in operators on primitive types). Please be excited for modules, coming out three years from now (plus implementation time).
C++17 is feature complete
https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/ Added stuff like: - a very limited destructuring syntax (structured bindings) (use case is for tuples; but likely to use a new reserved function name for general struct destructuring (like 'get<>()' or something); - template arguments that accept constant values of any type whatsoever 'template'; - 'constexpr if'; - specified order of evaluation for function calls and any syntax with arguments (including built-in operators on primitive types).
