Notices by John McCall (rjmccall@hachyderm.io), page 3

11:20 - There's a whole theory waiting to be written about representations of values, but you should not try to find out more by googling "representation theory"

13:32 - I had to cut this for time, but of course indirect enum cases don't use inline storage. Instead, indirect case payloads are stored in a case-specific heap allocation. Swift doesn't currently support mutating enum cases, but when we do, we expect that the language will implicitly use copy-on-write on these.

13:05 - This is a *huge* simplification to the point of being a lie. Array's single stored property is another struct, which itself has another struct as its single stored property. Eventually, on Apple platforms, that bottoms out as a Builtin.BridgeObject, which is essentially an optimized sum of either an ObjC or a Swift object reference. So it is a pointer that's referenced-counted at the end of the day, but there's a lot of extra stuff to it that I had to leave out.

We've been kicking around an idea to add a similar `indirect` feature for structs, so that you can very easily adopt copy-on-write on some or all of a struct's members. If we had that already, it would've made a really nice narrative for the upcoming section about getting value semantics with out-of-line storage! Alas.

@jsq @cocoaphony @kylebshr @justkwin @mergesort I definitely wouldn’t go so far as to say “no non-actor classes”! There are other ways to keep things isolated and thread-safe, like something isolated to the main actor, or just not sending it between concurrent domains

But yeah, we know we owe the community a guidebook here. We’re working on it, and seeing things like is a huge hint about places to flesh out

@cocoaphony @mergesort @kylebshr @justkwin @jsq Non-Sendability is the big tool there for when making something an actor isn’t right

@inthehands @yar @dgregor79 @ole I completely agree. Even if somehow you never write Rust again, being familiar with Rust's ownership concepts will be very helpful in using Swift's (should you need to)

@steve Hey, I know that guy.

He got pretty flustered after all the tech failures, really unprofessional

The revision of SE-0377 to make explicitly `borrowing` and `consuming` parameters require explicit copies has been accepted!
https://forums.swift.org/t/accepted-se-0377-revision-make-borrowing-and-consuming-parameters-require-explicit-copying-with-the-copy-operator/65293

I tried to say this at the panel tonight, but I muffed it; I’m sorry, it’s been a long day. #cppnow23

Programmers are often not very good at understanding when their code is security-sensitive