Guards comparison operator precedence and nesting

[bassjobsen]

As discussed at http://stackoverflow.com/questions/25287578/guards-with-multiple-conditions-nested-guards/ current implementation does not allow thing like not (a) and not (b), mainly due to the not keyword will be applies on the whole media query.

Possible solution are changing the precedence of the not keyword, adding a != comparison operator and / or allow nesting of conditions.

[lukeapage]

Seems like something that should be possible. I guess a != operator would be easiest

[matthew-dean]

As mentioned in #2072, the point about "not" applying to the whole conditional is a good one.

My only concern with != is that ! is somewhat a flag denotation for CSS (with important, but also we were discussing it as optional for extend keywords. So, to turn ! it into "not" sort of means the opposite of how it's used in CSS / Less. If "not" causes an implicit wrap around the following statement, we could just fix it with this change:

.gradient(@color, @start: 0, @stop: 0) when (not (@start = @color)) and (@stop = @color) { ... }

That way, it keeps "not" consistent in the sense that it applies to all conditionals within that "group", a "group" being defined by a matching set of parentheses (outside of not + conditional(s)).

This would leave the following behavior intact:

.gradient(@color, @start: 0, @stop: 0) when not (@start = @color) and (@stop = @color) { ... }

Since no outer "group" is defined, it's implied to include the entire when statement. Therefore, not applies to the entire statement.

What do you think?

[bassjobsen]

@matthew-dean i think your suggestion could fix this issue.
Or Use <> instead of !=.

[matthew-dean]

Or Use <> instead of !=

Or both? Support "grouped" conditionals with a not operator as well as <>? Both seem a logical fit.

[calvinjuarez]

Could we use >< instead of <>? I know it's a little thing, but <> reminds me strongly of HTML tags. Also, >< looks like a cute angry face, or an X, both of which seem to fit, to me, fsr.

[matthew-dean]

Could we use >< instead of <>

I'd prefer not to, since <> is the programming convention, and thus more likely to be understandable by developers.

[seven-phases-max]

Closing as fixed with #2763 (other features like != operator are to be subject for a dedicated tickets).