https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/

By 2020 C++ is planning to introduce:

* Ranges
* Contracts
* Concepts (`__traits`)
* Proper constexpr
* Modules
* Reflections
* Green threads

Right now it already has:

* `auto` variables
* Ranged for (`foreach`)
* Lambda expressions and closures
* `nothrow` attributes
* Proper containers
* Proper RAII

In no way this is the usual trollpost (I am a participant of SAoC). What bugs me is the shortening distance regarding what D has to offer with respect to C++. While D for sure has a way better syntax (thinking of template declarations, `immutable`, UDAs) and a GC, what are the advantages of using D vs C++ if my goal is to build a complex system / product?

TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/

According to https://medium.com/@wrongway4you/brief-article-on-c-modules-f58287a6c64:

"Compilation times are promised to become smaller up to 20%"

I think D's compilation times will still be significantly faster than C++. Especially when you consider that some library authors might even choose not to use C++ modules.. I think this is one place where D will still come ahead.

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/
>
> By 2020 C++ is planning to introduce:
>
> * Ranges
> * Contracts
> * Concepts (`__traits`)
> * Proper constexpr
> * Modules
> * Reflections
> * Green threads
>
> Right now it already has:
>
> * `auto` variables
> * Ranged for (`foreach`)
> * Lambda expressions and closures
> * `nothrow` attributes
> * Proper containers
> * Proper RAII
>
> In no way this is the usual trollpost (I am a participant of SAoC). What bugs me is the shortening distance regarding what D has to offer with respect to C++. While D for sure has a way better syntax (thinking of template declarations, `immutable`, UDAs) and a GC, what are the advantages of using D vs C++ if my goal is to build a complex system / product?
>
> TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

Not as many legacy features, such as the C preprocessor; much better syntax as you say, especially templates; no need to navigate enormously complex rules to make sure everything works; stuff they haven't added yet, like UFCS; and almost everything you list is available now, in 2018, so you get a giant head-start. :D

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/
>
> By 2020 C++ is planning to introduce:
>
> * Ranges
> * Contracts
> * Concepts (`__traits`)
> * Proper constexpr
> * Modules
> * Reflections
> * Green threads
>

Not all implementations are equal.

- Regarding `constexpr`

For example D's CTFE works by having some places where things are forced to be evaluated in CTFE. No syntax.
In C++, you currently have `constexpr` and soon you'll have `consteval` alongside with constexpr (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r2.html). No new keyword was used for the D version of CTFE.


Similarly, `if constexpr` is strictly less useful than `static if` since it introduces a scope. See the workaround here: https://stackoverflow.com/questions/46880578/scope-of-variables-declared-inside-if-constexpr-blocks < back to where we were with enable_if in terms of code size.


Regarding modules, they were proposed and reported in two C++ standards already.
Same for concepts.


Ultimately all this doesn't matter much since:
- the C++ culture of using cmake/makefiles over a declarative build system will not change (see the demise of biicode)
- avoiding the latest language addition to keep compatibility is necessary in C++, with divergent frontends
- existing codebases are still C++98 for the most part

D has the chance to have a community :
- for which template meta-programming is simple, well understood and almost boring
- which is willing to build an ecosystem (but not enough)

>
> what are the advantages of using D vs C++ if my goal is to build a complex system / product?

Easy: your struggle to learn the D language will have an ending. Which lead to reduced mental load forever - without compromising anything in power.


> TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

Sanity.

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

Nested functions.

On 15/11/2018 4:07 AM, lagfra wrote:
> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/ 
> 
> 
> By 2020 C++ is planning to introduce:
> 
> * Ranges

Really butchered. From what I can see they never mentioned D in any of the documents (kinda glad tbh). Those documents even question what it should be doing...

And the example code... yikes.
No way that is going to be used.

> * Contracts
> * Concepts (`__traits`)
> * Proper constexpr
> * Modules
> * Reflections
> * Green threads

Skepticism especially when there is 2023 being listed as a conservative estimate on the Reddit post.

On Wednesday, 14 November 2018 at 15:33:49 UTC, rikki cattermole wrote:
> [snip]
>
> Really butchered. From what I can see they never mentioned D in any of the documents (kinda glad tbh). Those documents even question what it should be doing...
>

I recall D being briefly mentioned in the Range specification. They rejected D's approach because they wanted to build on existing iterator-based code.

On Wednesday, 14 November 2018 at 15:49:48 UTC, jmh530 wrote:
> [snip]
>
> I recall D being briefly mentioned in the Range specification. They rejected D's approach because they wanted to build on existing iterator-based code.

It's actually quite a bit more than I remembered:

https://ericniebler.github.io/std/wg21/D4128.html#iterator-operations-are-primitive

On Wednesday, 14 November 2018 at 15:49:48 UTC, jmh530 wrote:
> On Wednesday, 14 November 2018 at 15:33:49 UTC, rikki cattermole wrote:
>> [snip]
>>
>> Really butchered. From what I can see they never mentioned D in any of the documents (kinda glad tbh). Those documents even question what it should be doing...
>>
>
> I recall D being briefly mentioned in the Range specification. They rejected D's approach because they wanted to build on existing iterator-based code.

No, it wasn't the reason. Some algorithms cannot be implemented with ranges as efficient as with iterators.

"In other words, by converting the is_word_boundary from iterators to D-style ranges, the algorithm goes from O(1) to O(N). From this we draw the following conclusion: D’s choice of algorithmic basis operations is inherently less efficient than C++’s."

C++ iterators are more flexible. I think of things like rotate and bringToFront - in C++ you need begin, end and middle iterators. In D you can't have something like a "middle", you have to pass two independent ranges. But since most algorithms require begin and end iterators I like D ranges because they aren't that verbose. But D ranges aren't always nicer, for example SList.insertAfter requires a hack with accepting Take!Range instead of just Range.

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:


> TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

Maybe nothing for some programmers. If C++ suddenly becomes a superior language in the future, I know I can start writing C++ and call my existing D code. That's one of the things that makes me comfortable writing D code today. I'll worry about your scenario when C++ is too tempting to avoid - something that is not true for me today.