Yes. If I were convinced as to the necessity of compile-time checking (I am not), I would be in favor of the compiler gaining abilities to check preconditions at compile time where possible. (This can be a general feature where the compiler emits a warning whenever it can prove that an expression is always optimized to a precondition failure.) I would not see any reason for fundamentally overhauling literals.
What are the motivations you have for “a better literals framework”? In my view, literals are already very complicated for users, and anything other than a simplification would be unwise.
Coercing a literal to a non-default type is already so confusing that SE-0213 was necessary to simplify the language and make things more predictable for users. The idea that we should add more functions to the 'as' operator seems completely beyond the pale when I would wager that the number of people who can enumerate all of the current functions of 'as', 'is', 'as?', and 'as!'—even in this forum—is in the single digits.
Not just you and I, I’d say. The overarching design of Swift leans heavily on trusting the compiler, and how things are optimized is invisible in the end user model. CoW “just works” but doesn’t come with its own keyword, whether something compiles down to a constant is completely opaque, and even fundamental language features such as for...in desugar to methods found in complex protocol hierarchies that are then optimized away by the compiler. What you assert is important to you is fundamentally not consistent with Swift’s overarching design.
Feel free not to continue the discussion further, but continuing it is in your interest if your aim is to overturn a fundamental design decision of the language.