-
Notifications
You must be signed in to change notification settings - Fork 689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement boolean assertion "statement" #3072
Comments
Sounds like a good idea to me (modulo bikeshedding). |
Should the desugared conditional negate the boolean expression? |
btw we have
(or optionally, introdice as
|
@grayjay you're right! I've updated the description accordingly |
@phadej that makes sense, but I'd consider that a separate issue feature-request; I'd also like the |
After two years, I still like |
@phadej the main problem with
has a different meaning/effect than
afaik, or is the plan to make it mean the same thing? regardless, I still think that more descriptive
it's more helpful than merely
Or for hackage revisions, an unconditional
instead of |
I hereby propose to add a new property/field
which would effectively provide syntax sugar for the following construct:
(or instead of
base<0
we could use anunbuildable
package)This would allow us to write things like
Or e.g. specify in platform specific packages such as 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 editassert
-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
The text was updated successfully, but these errors were encountered: