Absolutely. I was watching Alan Kay's "Inventing the Future" talks recorded a few years ago, and this was a thing he referred to in passing. In recent month's,

Absolutely. I was watching Alan Kay's "Inventing the Future" talks recorded a few years ago, and this was a thing he referred to in passing. In recent month's, every time I run across the whole "OO is evil/dead/horrible" meme (esp. common here) it turns out to be someone talking whose experience of "OO programming" is limited to C++/Java and their relatives. If your only exposure to OO was those (and similar) languages, then, YES, OO is horrible and weak and full of leakiness in the abstractions. It's a bit like saying that coffee is horrible when all you've ever tasted is cheap-and-nasty instant made from acorns and floor sweepings. C++ and Java (I can't comment on C#, never having used it in anger) are the palest, anaemic shadow of OO programming. Rant done. This addition to Swift might cause me to look at it more closely. (I don't have any reason/desire to touch the Apple grow-tunnel (as opposed to ecosystems, which are natural and open.) My thoughts have also recently run along lines of "What if we made every message to an object as if it were always remote (in another address space)?" In other words, for decades we've been trying to make RPC calls look (to the programmer) as if they were "just like local calls" and with justifiable lack of success because remote really is more wrinkly than local. So what if, instead of trying to make "remote" look/behave/imitate "local" we went in the other direction and make all calls look like remote calls? It means we have to think about all the failure modes and partial-failure modes of remote calls all of the time. Only, for local address-space calls, they're going to be much more reliable in practise. Is it worth it? Can we bring down the cognitive overhead to an acceptable level? I'm interested to see whether this Swift effort/initiative approaches this idealised/simplified description.