Implement boolean assertion "statement"

[hvr]

I hereby propose to add a new property/field

assert: <boolean-expression>

which would effectively provide syntax sugar for the following construct:

if !(<boolean-expression>)
    build-depends: base<0

(or instead of base<0 we could use an unbuildable package)

This would allow us to write things like

assert: impl(ghc >= 7.0 && < 8.0)

Or e.g. specify in platform specific packages such as Win32:

assert: os(win32)

Or even specify an unconditional assert: False for a broken package release.

The benefit of having a distinct form as opposed to the if/build-depends construct is that Cabal can recognise such forms easier, and provide better solver error messages. Moreover, the cabal edit validation in Hackage would be allowed to edit assert-properties, and be easier to implement robustly.
(currently you are not allowed to edit add/remove/change if-conditionals, and it's not trivial to specify under which circumstances such an edit would be safe)

/cc @kosmikus @dcoutts @bergmark @phadej

[23Skidoo]

Sounds like a good idea to me (modulo bikeshedding).

[grayjay]

Should the desugared conditional negate the boolean expression?

[phadej]

btw we have buildable: True and buildable: False; we could extend it to support

buildable: impl(ghc >= 7.0 && < 8.0)

(or optionally, introdice buildable-if:)

as assert: impl(ghc >= 7.0 && < 8.0) looks like

if !impl(ghc >= 7.0 && < 8.0)
  buildable: False

[hvr]

@grayjay you're right! I've updated the description accordingly

[hvr]

@phadej that makes sense, but I'd consider that a separate issue feature-request; I'd also like the default: <bool-value> property of flag definitions to be generalised to statically determinable boolean-expressions

[grayjay]

Related issue: #393

EDIT: #393 also suggests adding a field to warn that a configuration is sub-optimal.

[phadej]

After two years, I still like buildable: <bool expression> more than a new field.

[hvr]

@phadej the main problem with buildable is that it'd conflate component activation with a constraint... isn't it? I.e. currently

buildable: False

has a different meaning/effect than

build-depends: base<0

afaik, or is the plan to make it mean the same thing?

regardless, I still think that more descriptive fail: <message> (as suggested in #393) would allow us to describe the failure better to users... so e.g. if you have

if !os(linux)
  fail: This package will only ever support linux; maybe there is package foo-<otheros>

it's more helpful than merely

buildable: os(linux)

Or for hackage revisions, an unconditional

fail: this package is broken and is therefore blacklisted; see <issue-tracker-url> for more details

instead of build-depends: base<0 would also be able to provide better UX