I anticipate a long future of an ambiguous meaning of `@\unchecked Sendable`:

Meaning 1 (the official meaning):
This type is Sendable, but it cannot be proven due to limitations of the compiler, language, or frameworks.

Meaning 2 (the…other meaning):
This type is totally NOT Sendable, but I am way too tired to make it so. Please forgive me, those who suffer what I do today.

I fear in the not-to-distant future we will regret that these have the same spelling.

@cocoaphony there is also the mix of both. The type started as #1 but over time you make a subtle change that makes it NOT sendable but don’t notice it. The end result is that I’ll be assuming it’s #2 for every single unchecked type.
@cocoaphony Many people will never accept a force-unwrap even though it is super easy to do. I agree it isn’t as impactful, not by a long shot. But I think many developers will just not accept unchecked in the same way.

@mattiem I expect that, too. Unfortunately there isn't a particularly easy fix like there is for unwrapped optionals. So I expect a lot of frustration where people feel "unchecked is bad, but there's no solution."

I'm glad they used the word "unchecked" rather than "unsafe." That will help some.

But also…unchecked is kinda bad. You lose all checking for the type, and it's easy for the type to keep evolving and break what made unchecked ok.

@mattiem @cocoaphony maybe it should be `@uncheckedSendable!` heh bangs are scary

@cwagdev @cocoaphony ha!

But you know, I don't think you should be afraid of unchecked. I just think it always requires justification. Sometimes people are using it to "shut up the compiler" and I think that is something they will regret doing in the long run, even if it is really tempting right now.

@mattiem @cocoaphony I’d wager 90% of the usage is to shut up the compiler lol

@cocoaphony – Lol. Devs who mark something as “unchecked” Sendable without actually checking it themselves deserve what they get.

I find it especially imprudent when blithely applied to types for which they don’t have source code and couldn’t have possibly verified the sendability or lack thereof (notably Foundation types). IMHO, they shouldn’t even permit retroactive “unchecked” Sendable conformance, and should be limited to the original declaration.

@robertryan supporting a team of dozens of dev of many levels of experience, I’d like to build something better than “lol.” :) In particular, I face “it was carefully checked, but a year later it was modified.” I think it’s going to be a real challenge to separate proper from improper unchecked as time goes on.

Somewhat this has always been true of types that claim (or appear) to be thread-safe, but I worry it could undermine some of the promise we’re spending so much effort to realize.

@cocoaphony – Agreed. But, I guess I’m not understanding the broader point, then. Pre swift concurrency, we just had to use legacy tools (like TSAN) to verify. The compiler checks our Swift concurrency code for correctness for us, but if codebase has “unchecked sendable”, then it makes it explicit that that team must verify using legacy runtime techniques, just like always.

I'm not sure what else we can ask (my suggestion to prohibit after-the-fact sendability declarations notwithstanding)…

@cocoaphony – The situation seems to be analogous to how they tackled potential strong reference cycles. They said “we’ll let you reference `self` implicitly when there is no strong reference cycle risk, but you’ll have to do so explicitly in those cases where you open yourself to the risk.” Same with legacy thread-safety checks: “We’ll let you do it, but you now have to declare it explicitly so everyone knows that you’re operating without a net.” Not perfect, but a decent compromise, IMHO.