Part of that is the brain damage from C where asserts disappear in release builds. This relegates them to second-class, despite the fact that it is trivial to write the equivalent with an if statement and an early return.
Swift’s guard keyword is really nice. We could really use Eiffel-style invariants in our PLs now, IMO.
Disabling some of them in release builds makes sense. Like, say you have a binary search routine. It's totally fucked if the inputs aren't sorted, so you add that as an invariant. Now your log(n) performance sank to linear because you have to check the invariant. Invariants you can't express with your type system should have the option to have their checks disabled in release builds.
Fortunately assert is hardly part of the language itself, you can provide your own macro for it and you probably should.
Among other things you probably DO want to get rid of them when doing coverage analysis-- unless you like seeing your code base that truly has 100% branch coverage report as only having 30% coverage due to all the invariant checks that can't be triggered because the code isn't buggy.
I don't think asserts are really the best representation for constraints, but disabling them for release builds is entirely a question of your policy, and nothing fundamental at all - leave them on if you like. The real issue here with your early return rather than a panic, is what the semantics are for the caller.
Part of that is the brain damage from C where asserts disappear in release builds. This relegates them to second-class, despite the fact that it is trivial to write the equivalent with an if statement and an early return.
Swift’s guard keyword is really nice. We could really use Eiffel-style invariants in our PLs now, IMO.