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.
@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.
@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.
@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)…
jgarcia
Rob Napier
Bertrand Landry-Hétu
Matt Massicotte
Chris Wagner
Robert Ryan