On Tuesday, 19 November 2019 at 14:36:06 UTC, Ola Fosheim Grøstad wrote:
> I think library authors do, though. Anyway there are issues related to meta programming in C++, D, and Rust. But they all also improve on that for every significant version bump. Whoever stops evolving their metaprogramming features will fall behind.
>
> Rust is getting const generics eventually and C++ has added many library features and some minor language tweaks. It would be a good idea for D to make some statements about what is coming on the metaprogramming front.

Yes, I think some support for generic programming is generally expected from any modern programming language. This greatly benefits library authors and, in turn, library users. I'm not surprised that Go is also pursuing generics now.

But in my view it's not clear how far languages should take their MP (metaprogramming) support. D has more MP support than any other statically-typed language that I know of, but even D hasn't taken it to the extreme:
- It doesn't have AST macros and, as far as I know, there are no plans to ever include them in the language.
- Compile-time function evaluation is subject to various restrictions: for instance, you can't make arbitrary system calls. I'm not up to speed on the current limitations of the CTFE engine, but I believe W&A want compilation to be deterministic, and this naturally restricts the operations allowed at compile-time. (Someone please correct me if I'm wrong)

This brings to mind the adage "absolute power corrupts absolutely".

I can perfectly imagine a C# programmer (even library author) saying "I love generics, extension methods and lambda expressions, but that's good enough for me. I can live without `static if` and a full CTFE engine". That said, it's not like I've done a survey among the C#, Java, C++, Go, Rust, or Swift crowd. Maybe most programmers (or at least library authors) in these languages *do* wish for D-level MP support in their language. But that's a question that needs to be investigated; the answer is not obvious at all IMO.

On 19.11.19 17:11, Steven Schveighoffer wrote:
> On 11/19/19 9:55 AM, Ola Fosheim Gr wrote:
>> On Tuesday, 19 November 2019 at 14:36:06 UTC, Ola Fosheim Grøstad wrote:
>>> Whoever stops evolving their metaprogramming features will fall behind.
>>
>> Btw, Go is also actively pursuing generics now:
>>
>> https://go-review.googlesource.com/c/go/+/187317/
>> https://blog.golang.org/why-generics
> 
> Interesting they use the term "generics", it looks very much like they are putting in templates, which are vastly different from generics on many languages.
> ...

They do the type checking modularly, but it indeed appears they are not aiming to support generic methods on interfaces, directly contradicting:

"In Go, we’ve aimed to reduce complexity through independent, orthogonal language features that can be combined freely. We reduce complexity by making the individual features simple, and we maximize the benefit of the features by permitting their free combination. We want to do the same with generics."

Also:

- "The contract simply says that T has to implement the String method. You may notice that this contract looks like the fmt.Stringer interface, so it's worth pointing out that the argument of the ToStrings function is not a slice of fmt.Stringer."

- "After all, in Go, only built-in types support operators."


> It also looks like the call syntax does not use angle brackets, but just normal parentheses, a huge win for sure.
> 
> -Steve

It's another orthogonality violation. They don't support curried function definitions for other types of arguments.

(Of course, D is no more orthogonal, but it doesn't claim it as a core tenet.)

On Saturday, 23 November 2019 at 19:35:55 UTC, Mark wrote:
> But in my view it's not clear how far languages should take their MP (metaprogramming) support. D has more MP support than any other statically-typed language that I know of, but even D hasn't taken it to the extreme:
> - It doesn't have AST macros and, as far as I know, there are no plans to ever include them in the language.

Doesn't Nim have AST macros, though?  I haven't gotten around to trying Nim yet. Too many new compile-time languages...

> calls. I'm not up to speed on the current limitations of the CTFE engine, but I believe W&A want compilation to be deterministic, and this naturally restricts the operations allowed at compile-time.

Yes, C++ have some more limitations than D, but is fairly close. More restrictions seem to be lifted with each version (constexpr). Except of course, D allows building code from strings. I personally think that is one step to far, and would rather have used some kind of limited AST building capability, but many people seem to use string mixins. The question remains though: are they being used as a last resort or are they used in situations where more structured approaches would have been better?

One problem with string mixins is that source-to-source translation becomes very difficult. So then you cannot really improve the syntax, e.g. by machine translating all D2 source code to D3 source code(if it ever happens).

So there certainly are downsides to allowing this level of metaprogramming (string mixins/AST) in terms of being "forward compatible" (which requires the translation program to fully "understand" the old sourcecode).

The Go authors put a lot of emphasis on automatic source-to-source translation between versions. It will be interesting to see if they can keep delivering on that with Go2 after they get Generics in.

It clearly is a big advantage though, in terms of evolving a language over time.


> I can perfectly imagine a C# programmer (even library author) saying "I love generics, extension methods and lambda expressions, but that's good enough for me. I can live without `static if` and a full CTFE engine". That said, it's not like I've done a survey among the C#, Java, C++, Go, Rust, or Swift crowd.

C++ library authors have been using various involved template/multiple-inheritance techniques for the same effect. So they clearly see the value of being able to do it. And they also got "if constexpr" which is a limited version of "static if".


> Maybe most programmers (or at least library authors) in these languages *do* wish for D-level MP support in their language. But that's a question that needs to be investigated; the answer is not obvious at all IMO.

Yeah, well, I want good MP support, but I also want Go-style source-to-source translation so that language syntax (and semantics) improve over time and isn't locked down forever.

A hard nut to crack perhaps.

On Saturday, 23 November 2019 at 09:09:58 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 22 November 2019 at 14:31:46 UTC, Guillaume Piolat wrote:
>> With C++ you are also stuck in forever learning mode. Maybe learning the new move constructor stuff is going to make life easier? C++ is updated way faster than practionners can handle, strangely enough D has more respect for your time.
>
> Actually, that is a myth. There have been very few language changes in C++, and they are basically non-breaking. Most of the changes have been on a library level or as syntactical sugar.

That doesn't match my experience _at all_. Have you worked in C++ in a professional capacity?

C++ has a major version every 3 years, that comes with myriads of traps and new best practices.

The new stuff is non-breaking, except by living in that ecosystem you will inevitable be exposed to approximately all parts of the language. That's a huge mental load to spend.

Last time I touched C++ (2015) people were _in some companies_ starting to use C++11 (30% of it), because the compilers are necessarily lagging behind the C++ comittee.

To quote my competition:

> Now we have const, constexpr, if constexpr, consteval and std::is_constant_evaluated()
Who said C++ was hard to learn/teach?

On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat wrote:
> That doesn't match my experience _at all_. Have you worked in C++ in a professional capacity?

Please drop the ad hominems. It is completely irrelevant. (yes, but still 100% irrelevant).


> C++ has a major version every 3 years, that comes with myriads of traps and new best practices.

C++ is seeing growth because it is regularly updated.  That's just a fact.  So that is clearly not viewed as a problem with those that adopt it... (if it was there would be no growth).

However most of the _language_ changes are minor, and either syntactical sugar for common practice or simplifications of things that was a drag to write (e.g. template magic being replaced by CTFE). The biggest semantic change might actually be metaprogramming things like decltype(), but such changes are not revolutionary in any way.

Ref. https://en.cppreference.com/w/cpp/language/history C++20 langauge changes:

«
3-way comparison operator <=> and operator==() = default, designated initializers, init-statements and initializers in range-for, char8_t, [[no_unique_address]], [[likely]], [[unlikely]], pack-expansions in lambda captures, removed the requirement to use typename to disambiguate types in many contexts, consteval, further relaxed constexpr, signed integers are 2's complement, aggregate initialization using parentheses, array new can deduce array size
»

Basically _nothing_!


> The new stuff is non-breaking, except by living in that ecosystem you will inevitable be exposed to approximately all parts of the language.

Performance oriented libraries are usually conservative in what they use in the API?

Actually, many C++ codebases on github are C with a bit of C++ here and there...


>> Now we have const, constexpr, if constexpr, consteval and std::is_constant_evaluated()
> Who said C++ was hard to learn/teach?

Well, constexpr on functions is in the same vein as D attributes like "pure". It should have been the default.


Basically, if for a programmer with a good understanding of C++11 and common C++ patterns with templates then C++14/17/20 is not a big hurdle to overcome. Now, getting a good understanding of C+11 and common C++ meta-programming patterns is a big hurdle... but that has nothing to do with language changes. C++ has always been like that.

On Sunday, 24 November 2019 at 13:29:12 UTC, Ola Fosheim Grøstad wrote:
> C++ is seeing growth because it is regularly updated.

By what metrics C++ would be growing? Because it doesn't seem like the native space is expanding.

https://www.tiobe.com/tiobe-index/cplusplus/
https://www.youtube.com/watch?v=Og847HVwRSI&t=228

On Sunday, 24 November 2019 at 13:47:42 UTC, Guillaume Piolat wrote:
> On Sunday, 24 November 2019 at 13:29:12 UTC, Ola Fosheim Grøstad wrote:
>> C++ is seeing growth because it is regularly updated.
>
> By what metrics C++ would be growing? Because it doesn't seem

https://www.openhub.net/languages/compare?language_name%5B%5D=cpp&language_name%5B%5D=-1&measure=contributors

FWIW, C++ has always been a troubled language.

Cfront was slow.

After Cfront C++ compilers implemented C++ slightly differently so you could not easily write portable code.

After C++ was standardized compiler impementors had a hard time implementing all of it.

After most of it was implemented you'd still have to optimize your code in C-like manner as optimizers weren't on the level they are today. So you might start with something clean and end up with something you didn't like...

And you had to manage your own memory. And to use RAII you had write lots of verbose class descriptions.

Overall C++11/17/20 with clang/gcc is a much easier language to work with than C++ ever was. Everything is relative. But C++ has never been "clean". Ever.

D is clearly a much easier language to get started with in my opinion.

Although, if you read the C++ reddit, some C++ programmers claim that D is too similar to C++ to be worth the switch.  Maybe they are right, but D has much more room for making changes... C++'s backwards compatibility requirement is gridlocking the design space, so with every addition C++ is locked down more and more...

On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat wrote:
> On Saturday, 23 November 2019 at 09:09:58 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 22 November 2019 at 14:31:46 UTC, Guillaume Piolat wrote:
>>> With C++ you are also stuck in forever learning mode. Maybe learning the new move constructor stuff is going to make life easier? C++ is updated way faster than practionners can handle, strangely enough D has more respect for your time.
>>
>> Actually, that is a myth. There have been very few language changes in C++, and they are basically non-breaking. Most of the changes have been on a library level or as syntactical sugar.
>
> That doesn't match my experience _at all_. Have you worked in C++ in a professional capacity?

There's a big update every 6 years, with a minor update every 6 years, but an update every 3 years.

> Last time I touched C++ (2015) people were _in some companies_ starting to use C++11 (30% of it), because the compilers are necessarily lagging behind the C++ comittee.

I think a big part of that was because of MSVC. They weren't C++11 compliant for a long time. Now you do have clang on Windows and I think even chrome/firefox use it as their compiler of choice on Windows instead of Microsoft's compiler. Back then there wasn't really any other C++ compiler on Windows worth using. Both clang/MSVC are kept up to date pretty quickly now.

On Sunday, 24 November 2019 at 13:47:42 UTC, Guillaume Piolat wrote:
> On Sunday, 24 November 2019 at 13:29:12 UTC, Ola Fosheim Grøstad wrote:
>> C++ is seeing growth because it is regularly updated.
>
> By what metrics C++ would be growing? Because it doesn't seem like the native space is expanding.
>
> https://www.tiobe.com/tiobe-index/cplusplus/
> https://www.youtube.com/watch?v=Og847HVwRSI&t=228

By being the go to language in game engines, GPGPU (NVIDIA now designs their cards to be ISO C++ friendly), the language that is used in Metal shaders and IO Kit, the rewrite from React Native for Windows and OS X taken up by Microsoft, what gets called from Java/.NET when extra native help is needed,....

Now if the metric is having GUI toolkits in C++, like those from the 90's, then yeah it pretty much lost it, with Qt, WinUI and wxWidgets being the last ones standing.

Or doing stuff like CMS. Hope no one is doing them in C++.

On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
> On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat wrote:
>> [...]
>
> There's a big update every 6 years, with a minor update every 6 years, but an update every 3 years.
>
>> [...]
>
> I think a big part of that was because of MSVC. They weren't C++11 compliant for a long time. Now you do have clang on Windows and I think even chrome/firefox use it as their compiler of choice on Windows instead of Microsoft's compiler. Back then there wasn't really any other C++ compiler on Windows worth using. Both clang/MSVC are kept up to date pretty quickly now.

Other than Intel, PGI and Codegear.