Badly formed pre/post conditions silently passed

Description

Before:

After:

Patch: CLJ-1473_v03.patch
Screened by: Alex Miller

Environment

None

Activity

Show:
Andy Fingerhut
November 15, 2015, 8:39 PM

Eastwood 0.2.2, released on Nov 15 2015, will warn about several kinds of incorrect pre and postconditions. See https://github.com/jonase/eastwood#wrong-pre-post

The Eastwood documentation may be misleading right now, in that it says that re and ost should be vectors, which is at odds with Rich's comment of Oct 9 2015. Corrections to Eastwood's documentation here are welcome. I guess Rich's intent is that re and ost could be vectors, lists, or sets? Would a map ever make sense there?

import
January 31, 2018, 4:58 PM

Comment made by: marco.m

Hello any news ?

Alex Miller
August 2, 2018, 8:49 PM

There's feedback above from Rich that has never been addressed here. I took a stab at an update, but relaxing the constraint to just "collections of expressions" is kind of interesting. Once you do that, then the first example in the ticket here {re (pos? x)} is actually not invalid, it's a collection of two things: pos? and x. pos? evaluates to true (it's a function) and x evaluates to true for any number.

I'm not sure what the way forward is on that. It's perfectly valid and even potentially useful to refer to an incoming arg as a precondition, which would just be a symbol:

Maybe you could check for whether the elements of pre or post are either lists (expressions) or symbols that are arg bindings? Anything else is vacuously true and probably a bug. Not sure.

Andy Fingerhut
August 3, 2018, 10:05 AM

Eastwood still gives warnings about code like the following:

Here is sample output:

It also still warns if the value of re or ost is not a vector, despite Rich's comment, so it is overly strict in that sense, but maybe not so bad to be overly strict there.

Martin Klepsch
December 19, 2018, 2:29 PM

Just want to point to this PR (https://github.com/pedestal/pedestal/pull/544) as an example of how this affects production Clojure code.

Due to malformed pre/post conditions silently being accepted the API was essentially different from what the library authors intended. People started to rely on this and fixing the broken precondition essentially resulted in a breaking change.

Assignee

Unassigned

Reporter

Brandon Bloom

Labels

Approval

Triaged

Patch

Code and Test

Priority

Major