New function colour: unsafe

[Karl]

I think the precedent for not annotating unsafe APIs came from withContiguousStorageIfAvailable. I had a look and I'm not able to find those discussions, but I'm quite sure it was argued that this should have "unsafe" in the name, and that the core team rejected that idea. Does anybody else remember that?

String.withUTF8 simply follows that precedent.

It's not necessarily just a problem of lacking the tools to annotate unsafe APIs; I think there has been what I can only describe as a cultural shift to put brevity above consistently communicating safety - we could have added the word "unsafe" to the above APIs to make things clearer at the call-site, but it was decided not to do that.

Now, especially when it comes to things like the concurrency, I feel that new APIs are being somewhat rushed, and that we should take the time to innovate in this space and consider ways to protect developers from making mistakes (because everyone - even experts - can make mistakes). For example, I outlined one way in which I think we could make custom actor executors safer:

@Karl

I'm really uncomfortable with the unownedExecutor requirement for actors. I know that it already exists, but I think it goes against everything we've tried to achieve in Swift with regards to safety. In the best case, it's a pointer and we just hope that keeping the actor alive is enough to keep the executor alive as well; and in the worst case, you can return different executors every time and defeat all of the data race safety that we hope to achieve with language-integrated concurrency.

I think it it worth exploring safer designs here. For instance, distributed actors have a synthesised actorSystem stored property which must be set. I think a similar design could work for the executor of a regular actor:

distributed actor Greeter {
  init(name: String, actorSystem: ActorSystem) {
    self.name = name
    self.actorSystem = actorSystem // required (!) initialization of implicit actorSystem property
  }
}

That way, we could guarantee the invariant that executors will live for as long as there are any actors which use them, that the executor cannot be changed after initialisation, and that all accesses to the synthesised property return the same executor instance. That's at least something.

If an actor does not explicitly initialise its executor, it would be initialised to a default executor.

This didn't happen. It was called "interesting" and suggested that maybe we'll investigate it one day - but personally I'm not optimistic; I think we're going to move on and forget all about it, or it'll become impossible to add later due to backwards compatibility. Personally, I think safety should be a major blocking issue rather than an afterthought or something to try patching in later, and that it warrants in-depth investigation before a feature is allowed to ship, but it seems the language workgroup do not agree.

Which leads me to reiterate the point I made above about APIs such as wCSIA and withUTF8 - I feel like it's a cultural shift. It's not a problem that can be fixed by adding a new function colour.