My instinct says 'yes'. But i also have a feeling that im going to run into problems that current languages dont have. Such as being forced to copy data or have complex systems like in rust to make the compiler happy.
My instinct says 'yes'. But i also have a feeling that im going to run into problems that current languages dont have. Such as being forced to copy data or have complex systems like in rust to make the compiler happy.
I'm unsure what you mean here. It's pretty foundational to the structuring of programs hierarchically (eg, trees own their children, functions own their variables, closures own their environments, and so on).
The classic argument against ownership as a language semantic is that it doesn't play well with graphs and circularly linked lists, where there isn't a meaningful hierarchy and therefore no one ancestor is the "owner" of any descendant. The counterargument is that these datastructures are both rare and better represented with a single owner of the data and the relationships represented through indirection even if your implementation language doesn't enforce ownership (for example, adjacency lists/matrices for graphs, vectors for lists, etc).
Interesting arguments. Thanks.
A modern definition could be that ownership semantics define how aliases to data are created and shared. This includes things like variable binding and class members, but also encapsulates pointers and references - which have formal semantics in every language that uses them (and therefore, bake in ownership, even if it is implicit).
In systems programming languages like C and C++ the word "owner" and "ownership" are often used to describe which data structures and calling contexts are responsible for managing data lifetimes, since aliases to that data are used to control memory allocation and deallocation. The semantics are not baked into the language, but most software in these ecosystems has to be written with ownership in mind to be sound - and indeed, has been for many years, with that verbiage ("lifetime", "owner", etc).
Similarly, having a clear idea of ownership can help in writing GC friendly code.
For a higher level hobby language I’m designing, I’m thinking of doing a similar concept, but with runtime overhead - basically every object would be “synchronized” in Java’s parlance, but to make it efficient most lockings would be elided at compile time via move semantics. So data races couldn’t happen (also, could possibly do a better job at escape analysis).
The primary reason I’m thinking about that is that we really shouldn’t be using non-thread safe primitives anymore — Clojure did get this right. That should be left as a compiler optimization if it can prove that that given code runs inside a “alone”.
Not if you live in a communist society.
I think it would be better if there was no ownership, because everybody would be happy.
It means no private ownership of the means of production, which another can of worms.
Coincidentally, worms are an excellent source of protein in this communist, Marxist society. By eating worms instead of beef, it will also help to stop climate change by eliminating the greenhouse gases from cows, thus saving the planet. You will eat ze bugs!