So I’m relatively neutral on this specific proposal, but I think it’s worth highlighting an important feature of the compile-time vs. test-time nature of this, specifically in terms of cycle time for development. In my experience, there seem to be rough order-of-magnitude differences between the feedback you get from—
- the compiler (especially with RLS)
- automated test suites (assuming they’re running on every build change)
- manual local testing
- CI (presumably == automated equivalent of what you do in 2 and 3)
- deploying to staging (for manual testing)
- deploying to live (i.e. when production traffic is meaningfully different from what you can test on staging)
That doesn’t mean we should put everything in the compiler all the time. Indeed, there are some things it is too expensive or difficult to test anywhere but production (all the way up at layer 6)! However, I think explicitly being aware of the cost in cycle time is useful, and being explicit about why we think it’s worth slotting into layer 2 vs. layer 1 (or layer 3 or 4 or 5 or 6!).
I think a lot of people who end up in Rust tend to prefer putting as much as possible into layer 1 here because we have so often been bitten by things that are at layer 2 in other languages or frameworks and take a lot of time to figure out why they broke at layer 2. This happened to me in a C♯ app just last week, and chasing it down was not fun.
Again: that’s not an argument for what to do in this case; it’s just trying to make explicit what I think is implicit in a lot of these discussions so it can be more effectively discussed.
Edit: I am going to extract this and elaborate on it slightly and turn it into a blog post. Seems more generally useful. 
Edit later with the promised post: Scales of Feedback Time in Software Development