for core D devs. Of course, this is much easier in D than in C++ because of D's const and pure attributes.

"Functional Programming in C++" by John Carmack

https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php

I'm as guilty as anyone for not understanding or following these guidelines. I expect we can do much better.

On Wednesday, 25 October 2017 at 22:19:21 UTC, Walter Bright wrote:
> for core D devs. Of course, this is much easier in D than in C++ because of D's const and pure attributes.

"But master," the apprentice started.. but the master interrupted, asking:

"Is it not true that the word for 'not functional' is 'dysfunctional'?"

And then the apprentice understood.

https://medium.com/javascript-scene/the-dao-of-immutability-9f91a70c88cd

On Wednesday, 25 October 2017 at 22:19:21 UTC, Walter Bright wrote:
> for core D devs. Of course, this is much easier in D than in C++ because of D's const and pure attributes.

Nah, the type system isn't critical for doing functional style programming. People who want to do functional programming in C++ has plenty of opportunities, and libraries to support it…

> "Functional Programming in C++" by John Carmack

2012, and it doesn't really say anything, does it?

On Saturday, October 28, 2017 21:51:50 Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Wednesday, 25 October 2017 at 22:19:21 UTC, Walter Bright
>
> wrote:
> > for core D devs. Of course, this is much easier in D than in C++ because of D's const and pure attributes.
>
> Nah, the type system isn't critical for doing functional style programming. People who want to do functional programming in C++ has plenty of opportunities, and libraries to support it…

The type system can help ensure the correctness of functional programming (e.g. pure helps ensure that you didn't accidentally do something involving global variables), but it's certainly not required to write in that style.

And actually, most D code that's functional doesn't do much with either const or pure. Most of the functional code is range-based, which fundamentally falls apart with const - at most, const or immutable is used for the elements. And while pure is often involved, it's typically only by inference. So, in those cases, the only places that pure actually gets checked is in unittest blocks marked with pure or when you try to use a set of range-based operations inside of a function that you've marked as pure. And range-based operations that definitely aren't pure are done on a regular basis (e.g. any lazy ranges grabbing their elements from I/O).

So, arguably, D is already showing how unnecessary const and pure are for functional programming. They can help, to be sure, but they aren't necessary.

- Jonathan M Davis

On Saturday, 28 October 2017 at 23:26:11 UTC, Jonathan M Davis wrote:
> The type system can help ensure the correctness of functional programming (e.g. pure helps ensure that you didn't accidentally do something involving global variables), but it's certainly not required to write in that style.

Yes, the type-system would prevent some aspects of non-functional programming, but it doesn't enable functional programming…

Anyway, both C++ and D have abstraction mechanisms for building the tools you need to get functional-style programming. And I assume production backends also do tail-call optimization in D as well as C++.

What you don't get in either is a convenient applicative pattern matching syntax, and functional programming in the technical recursive sense is mostly not a very good idea (even with tail call optimization since you cannot enforce it, I think?).

Anyway, with the improvements to C++ lambdas it has become more attractive to do small-scale functional style programming in C++. So I think D and C++ are pretty much the same in that respect. (D has pure, but C++ has explicit capturing of references)

> And actually, most D code that's functional doesn't do much with either const or pure. Most of the functional code is range-based,

I guess it makes sense to call range-based programming functional in spirit (although not so much on a technical level, e.g. recursiveness). And you can do similar things with iterators, although the C++ stdlib does not provide much out-of-the-box.

In the context of the linked article I think maybe he is assuming that you should have SIMD access to the values, so maybe there is an underlying assumption there that libraries for ranges/iterators don't support SIMD well in their current incarnations.

Anyway, I think you can rely on RVO in  C++ in 2017, maybe not in 2012. But the addition of constexpr to C++ has made some improvements to the C++ ecosystem where D used to be a little bit ahead.

The improvements to C++ in C++14 and C++17 are relative small, but as far as I am concerned, those improvements has enabled a more functional style of programming for initialization (small scale functional programming).

Ola.