www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++17 is feature complete

reply Enamex <enamex+d outlook.com> writes:
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<auto Arg>';
   - 'constexpr if';
   - specified order of evaluation for function calls and any 
syntax with arguments (including built-in operators on primitive 
types).
Jun 26 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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<auto Arg>';
   - '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).
Jun 26 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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").
Jun 26 2016
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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?
Jun 26 2016
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2016 10:18 AM, Enamex wrote:
   - template arguments that accept constant values of any type whatsoever
 'template<auto Arg>';
Still adding D features, I see!
Jun 26 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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<auto Arg>';
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.
Jun 26 2016
prev sibling next sibling parent mogu <mogucpp 163.com> writes:
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<auto Arg>';
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?
Jun 26 2016
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
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<auto Arg>';
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.
Jun 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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<auto Arg>';
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.
Jun 26 2016
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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<auto Arg>';
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.
Jun 27 2016
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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<auto Arg>';
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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 27 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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++.
Jun 27 2016
prev sibling next sibling parent reply luminousone <rd.hunt gmail.com> writes:
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<auto Arg>';
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++?).
Jun 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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<auto Arg>';
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
Jun 26 2016
parent reply luminousone <rd.hunt gmail.com> writes:
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<auto Arg>';
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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
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. 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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 27 2016
next sibling parent reply default0 <Kevin.Labschek gmx.de> writes:
Regarding C++ I found this to be a fun read: 
http://yosefk.com/c++fqa/ :-)
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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. ;-/
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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?
Jun 27 2016
parent reply Enamex <enamex+d outlook.com> writes:
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).
Jun 28 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 28 2016
parent reply Enamex <enamex+d outlook.com> writes:
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.
Jun 29 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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
Jun 29 2016
prev sibling parent reply luminousone <rd.hunt gmail.com> writes:
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.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 27 2016
parent luminousone <rd.hunt gmail.com> writes:
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.
Jun 27 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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<auto Arg>';
Still adding D features, I see!
constexpr if looks a lot like static if to me.
Jun 27 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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<auto Arg>';
Still adding D features, I see!
constexpr if looks a lot like static if to me.
You're not alone on that one.
Jun 27 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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<auto Arg>';
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); }
Jun 27 2016
prev sibling parent Enamex <enamex+d outlook.com> writes:
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
Jul 07 2016