[swift-evolution] Rename 'guard' to 'ensure'

Dave Abrahams dabrahams at apple.com
Mon Feb 22 17:48:58 CST 2016

on Mon Feb 22 2016, Greg Parker <swift-evolution at swift.org> wrote:

>> On Feb 22, 2016, at 10:15 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> on Mon Feb 22 2016, Erica Sadun <swift-evolution at swift.org> wrote:
>>> On the other hand, I'd love if assert/precondition would be combined
>>> into a single call, with an optional `forReleaseBuild:` arg (better
>>> named) that defaults to false.
>> I really don't want to do that.  Assert and precondition have different
>> use-cases, and I don't want people to ask “do I want this on in a
>> release build?” (which is a hard decision to make correctly and
>> consistently) when they write them.  I want them to ask, “Am I checking
>> whether this method is being called correctly or is this just a
>> self-sanity check?”
> Conversely, "do I want this on in a release build" is precisely the
> decision I usually make in my own code. The dichotomy is not parameter
> validation versus sanity checks. Instead the dichotomy is checks that
> are fast enough for release builds versus checks that are too slow or
> have rare false positives and must be left only for non-release
> builds. "assert" and "precondition" are not useful names for that
> usage.

Well, I'd be open to a proposal for a checkInReleaseBuilds: Bool = false
parameter to assert, for those people who want to run their sanity
checks in release builds, but I don't think I want to retire precondition().


More information about the swift-evolution mailing list