> That's a feature of the references, not of objects.
That doesn't seem like an unreasonable way to draw the lines.
> The sharing and overlapping of data slots is however an inherent feature of closures.
Is it? When defining a lambda in C++ you can choose for things to be captured by copy rather than reference. I agree with saying that a function that captures nothing is "not a closure", but I don't know that I'd say the same about something that captures only by copy. Would you say that a language that only supported capture-by-copy "lacks closures"?
> That doesn't seem like an unreasonable way to draw the lines.
It's a turing tarpit otherwise, after all.
Regarding C++, I've not used the newer versions, but using that feature to capture only copies would match what I said upstream, as a limited usage of closures that would happen to match objects, while closures themselves can do more. Capturing by copy also means that it's instantiating a new closure variable slot specific to the copy, and is no longer closing over the original variable, so it's an additional step on top of the fundamental closure mechanism which would by nature be agnostic to private vs shared variable slots.
That doesn't seem like an unreasonable way to draw the lines.
> The sharing and overlapping of data slots is however an inherent feature of closures.
Is it? When defining a lambda in C++ you can choose for things to be captured by copy rather than reference. I agree with saying that a function that captures nothing is "not a closure", but I don't know that I'd say the same about something that captures only by copy. Would you say that a language that only supported capture-by-copy "lacks closures"?