[swift-evolution] Support for assertions/preconditions that sometimes fail.

Dave Abrahams dabrahams at apple.com
Sat Jan 14 21:03:35 CST 2017


on Sat Jan 14 2017, Tony Allevato <swift-evolution at swift.org> wrote:

> This sounds like a problem that a third-party logging API could handle
> easily, and there's nothing about Swift's current implementation blocking
> you or someone else from writing one.
>
> It feels like a fairly specialized use case—it's hard to see it being
> fundamental enough to argue that it be part of the standard library.

It's a very interesting idea, but as Tony notes, it's fairly
specialized.  More importantly, it's completely untested.  To clarify
our scope here,

  In general, any APIs proposed for the standard library should have
  broad applicability, and whenever possible the ideas should have
  precedent in a real existing implementation that many people have
  found useful.

That argues for doing what Tony suggests—implement your idea, use it,
put out a SwiftPM package, and refine it with the help of your users'
feedback—before bringing it back to Swift-evolution.

> On Sat, Jan 14, 2017 at 5:12 PM Amir Michail via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Jan 14, 2017, at 8:00 PM, Saagar Jha <saagar at saagarjha.com> wrote:
>> >
>> > Why not just add a // TODO or // FIXME comment?
>> >
>>
>> There is no bug. Moreover, you want something that actually executes and
>> that can give you useful information when the program finishes running.
>>
>> > Saagar Jha
>> >
>> >> On Jan 14, 2017, at 4:10 PM, Amir Michail via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>
>> >> It’s quite common for an assertion/precondition that you thought should
>> hold actually does not yet there is no bug. In that case, you might want to
>> remind yourself of this fact by commenting out the assertion/precondition
>> (instead of deleting it) so that you don’t make the same mistake in the
>> future by inserting such assertions/preconditions into the code.
>> >>
>> >> However, it would be nice to have explicit support for
>> assertions/preconditions that don’t always hold where there is no bug.
>> >>
>> >> For example:
>> >>
>> >> preconditionNotAlwaysTrue( list.isEmpty )
>> >>
>> >> When your app finishes running, the IDE could show you all such
>> preconditions/assertions that you thought fail sometimes that did not fail
>> in that particular run. In that case, you might consider switching them to
>> normal preconditions/assertions provided your code has now evolved to the
>> point where they always hold.
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

Cheers,

-- 
-Dave



More information about the swift-evolution mailing list