How to express logic "and","or", "not"?

[zhaopengme]

"and" is and.

"or" is or.

but what is "not" ?

thanks!

[nickpearson]

To work around this, I've always used nested if/unless statements, which isn't pretty but it works.

So, if you have this in a language that has a not operator:

if a && b && !c
  # ...
end

then you can do this in Liquid:

{% if a and b %}
  {% unless c %}
    ...
  {% endunless %}
{% endif %}

It can get tricky if you need complex else logic, but most times this works for me.

[phoet]

@dapengme what is your specific usecase? you can also use var != 'value'

[fw42]

Since this is not really an issue but more of a question, and it's pretty old, I will close this for now. Please re-open if necessary.

[retorquere]

Without "not", it is quite awkward to express something like "if not p.url contains '/'"

[pathawks]

if not p.url contains '/'

unless p.url contains '/'?

[retorquere]

That works only for simple, not combined conditions. I've worked around it, but "not" is a legitimate boolop that is not entirely replacable by unless.

[cam]

Sometimes it would make a lot more sense to have things that behave like "does not contain", rather than an "unless" statement. It would keep things cleaner and offer more options.

[courtyenn]

I agree with Cam and AllThatIsTheCase. It is difficult to check if, for example, a collection of product.tags and customer.tags do not contain the tag "wholesale" without a "not contains" operator because of the combined condition.

[fw42]

Reopened because of #526

[Blaisorblade]

From #526:

same way having support for parentheses would be nice to have

Ah. Sounds like the problem is the parser support for not, because you're not using a parser generator or something like that — and you can't parse the context free grammar of expressions with parentheses with regular expressions such as

liquid/lib/liquid/tags/if.rb

Line 14 in 12d526a

ExpressionsAndOperators = /(?:\b(?:\s?and\s?|\s?or\s?)\b|(?:\s*(?!\b(?:\s?and\s?|\s?or\s?)\b)(?:#{QuotedFragment}|\S+)\s*)+)/o

. I see why this is not on your roadmap — you'd need to replace that part of the parser.

[fw42]

@trishume and @pushrax might have thoughts

[pushrax]

We could totally implement parentheses with the new parsers, but it would probably break some templates that are using them regardless of whether they do anything or not. We even have a test asserting that parentheses are broken :(

If this feature is wanted, though, I would be happy to do the necessary work, which would include killing certain portions of the lax parser (which we want to do eventually anyway, right?)