Not exactly the same thing, but maybe JavaScript's fat arrow function? It originally appeared in CoffeeScript, which is a language that adds some syntactic sugar to JavaScript, and then eventually it found it's way into the JavaScript language. Now most people probably associate it with JavaScript, since CoffeeScript isn't nearly as well known.
Common Lisp had an object system from way back when. I seem to recall the general opinion on it was "who needs objects?" for a while, and then after objects took over the rest of the world, the talk seemed to shift to "our object system is better!"
Rails didn't take a good thing and make it popular. It took a shit thing and gave people a reason to put up with it. There's a reason no one uses Ruby outside of Rails...
I think folds and such started in functional languages, were then adopted by imperative languages, which then made them prettier as comprehensions, which then made their way back into functional languages. But it could be that both features went one way.
Both features went one way. Comprehensions were introduced in the functional language Miranda (and to a limited extent its predecessor KRC) back in the 1980s.
Maybe python poetry? And pep 518. Rust designed cargo after pip and python setup.py and made it better. Then pep 518 was inspired by cargo, and now pyproject.toml works pretty much the same way.
C++98/C++03 give no real consideration to multithreaded code, which means that optimizers were free to work on the basis of preserving only single-threaded correctness (and they did!). The only tools you have at your disposal are inline assembly, external function calls acting as natural barriers, and (misusing) volatile. (Or maybe you have compiler-specific builtins, e.g., the GCC __sync_ builtins).
In terms of changes to semantics of pre-C++11 code, the biggest change is that the compiler is no longer able to introduce stores to memory locations that would not have been stored normally. This prohibits the optimization that would change this loop:
for (int i = 0; i < N; i++)
*res += A[i];
into this:
int temp = *res;
for (int i = 0; i < N; i++)
temp += A[i];
*res = temp;
(since res would not have been written if N were 0 or less).
Beyond that, the main effect is that it is now possible to write correct multi-threaded, lock-free code without having to rely on the scattershot nature of volatile. Volatile does not mean what many people take it to mean. The closest approximation to its actual semantics in practice is that any load or store instruction generated from a volatile must not be reordered (with respect only to other such load/store instructions), and it must not be removed (i.e., no dead-store elimination or hoisting outside a loop). In particular, volatile does not prohibit load/store tearing (e.g., reading a 64-bit location via two separate 32-bit loads); it does not prohibit other accesses from being widened to include the volatile memory address.
I know. But I think Java had them before C++, and I think that Java was the first mainstream, C++-syntax, object-oriented language to have them. (Yeah, I know, that's not saying much, because C++ and Java are the only two mainstream, C++-syntax, object-oriented languages.) The point was, C++ could have looked at Java as proof that a language like C++ could have closures, and so one could suspect that the immediate, direct inspiration was from Java.
I only mentioned closures because it's the only feature I could think of that C++ has, but Java had first. (I welcome other examples, if anyone has them.)
C# was the first mainstream language with a C-style syntax to have them - anonymous delegates in C# 2 (2005), then lambdas with type inference in C# 4 (2010).
Java got them in Java 7 in 2011, more or less at the same time as C++11 did.
In any case, Java and C# closures weren't particularly helpful to C++, because they have only shown that a garbage-collected language can have them - the main complexity around closures is wrt memory management and ownership. Hence why C++ closures are very different from either Java or C#.
I suspect that C++ got the now-deprecated exception specifiers - throw() on functions - from Java. But not entirely sure.
I checked my copy of the C++ Programming Language (2nd edition, 1991) which has throw() exception specifiers on functions. The Java project started in 1991.
I'm not sure these qualify as closures. But if they do, then they've been around in that exact form (named local functions with language semantics preventing them from outliving their environment) since Algol-60.
> I have no idea what the c++ committee were using as predicates
And in fairness, neither do I. My point wasn't "C++ copied closures from Java". My point was "I can't think of anything else they copied from Java", and therefore that I suspected that the answer to jedberg's question was no.
