LESS docs on guarded mixins — why will this rule n

问题:

Having primarily used SASS when writing CSS, I am now preparing to try out LESS as well. Having a read through the docs, I'm confused with the following in the context of guarded mixins:

Additionally, the keyword true is the only truthy value, making these two mixins equivalent:

.truth (@a) when (@a) { ... }
.truth (@a) when (@a = true) { ... }

Any value other than the keyword true is falsy:

.class {   
  .truth(40); // Will not match any of the above definitions.
}

Why will truth(40) not match the first mixin? Doesn't when (@a) simply state that only match the mixin if a value (any value) is given to @a, essentially, if @a exists? And since 40 is a value that exists, why would it not find a match in the given mixins?

回答1:

For Conciseness...

...I think. It appears to be assumed by the programmers of LESS that if you do not want a guard on the mixin, then you of course put no when statement at all:

.truth(@a) { ... }

This mixin is called regardless of the value of @a, but does require a value for @a, and so is checking by default for "existence" of a value. So by the adding of a when guard, they have assumed one does indeed intend a further guard (and not just to allow any value), and so...

.truth (@a) when (@a) { ... }

...makes for a shorthand way (LESS is about trying to speed coding) of writing the guard statement...

.truth (@a) when (@a = true) { ... }

This makes for faster coding of a mere true/false switch for a guard, and probably seemed to be good sense over what would otherwise be a redundant statement if it instead evaluated the when (@a) as true for any value.

It is, admittedly, a bit less intuitive (no pun intended) from a typical programming viewpoint where it would seem that if @a exists (as in, anything other than false, null, or 0) then the phrase when (@a) would evaluate to true. But instead of checking for "existence" of a value, they have made that check an explicit check for a passed value of true (their only "truthy value" as far as guards are concerned).

I don't have any documentation to back up my statements here, other than the statements on lesscss.org about how they have coded it, which state nothing about why they coded it to work that way (that part is my speculation at present, unless I can track down documentation of discussion about it).