Support for assertions/preconditions that sometimes fail.


(Amir Michail) #1

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.


(Saagar Jha) #2

Why not just add a // TODO or // FIXME comment?

Saagar Jha

···

On Jan 14, 2017, at 4:10 PM, Amir Michail via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Amir Michail) #3

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.

···

On Jan 14, 2017, at 8:00 PM, Saagar Jha <saagar@saagarjha.com> wrote:

Saagar Jha

On Jan 14, 2017, at 4:10 PM, Amir Michail via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Allevato) #4

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.

···

On Sat, Jan 14, 2017 at 5:12 PM Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

> On Jan 14, 2017, at 8:00 PM, Saagar Jha <saagar@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #5

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, Tony Allevato <swift-evolution@swift.org> wrote:

On Sat, Jan 14, 2017 at 5:12 PM Amir Michail via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jan 14, 2017, at 8:00 PM, Saagar Jha <saagar@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Cheers,

--
-Dave