being “lightweight” is a secondary concern to me. the predominant concern is the simple fact that assertions, well, crash the process. i understand this is annoying but not catastrophic for client-side applications. therefore, when developing those sorts of applications, assert early and assert often is good practice. but the game is very different when you’re developing on the server. crashing on precondition failure is highly damaging to server-side applications, even in the best case scenario where the daemon comes back online promptly, because if you crashed while a request from say, Googlebot, was in flight, well you’ve got a really tough month ahead of you.
this isn’t as tangential as it might seem. one of the things that Swift lacks compared to other languages is a mechanism for recovering from an assertion failure. throws is not sufficient for this use case, because there are a lot of constructs in the language (properties, subscripts) that don’t support throws. this feels pretty closely related to testing fatal errors which is something that would fill a huge gap in our tooling.