Omitting "&" on an "& when" block

[matthew-dean]

Moving this discussion from #1293

There was a comment today on issue #1293 that got me thinking about the & when statement often used as a stand-in for an "if" statement. (Yes, not a one-to-one stand-in, I don't want to open a side-track of imperative v. declarative keywords.)

One thing that occurred to me about this. We had discussed @when in issue #2072, but some of the resistance to @when in the original discussion is the additional at-rule. However, thinking about it now, it shouldn't be needed.

Considering that these two blocks are equal:

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

Then these two statements should also be accepted by the parser as equal.

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

If for no other reason than & when is syntactically awkward. Omitting & to still imply a selector join with the parent selector has existed all along, so omitting & to imply a guard on the parent selector doesn't seem like a leap. Also, block-root functions are now accepted by the parser for use with plugins, so it no longer looks as strange as it might have in 2013.

I feel when () would be a bit easier for new Less users to understand than & when() if we just say, "For now, pretend that when() means if() and we'll get to the more advanced reasons about the differences later." I mean, we don't have to explicitly state that in the documentation. It just requires a little less understanding of Less's use of & and such to get how to use it. And the syntax is cleaner. It's just a small trim on the syntax.

[seven-phases-max]

The argument is quite artificial. A contra-arg using equal analogy:

.a {
    & { color: blue; } // OK
}
.a {
    { color: blue; } // Error
}

In general, I would not mind any less verbose and less cluttered syntax but this particular case this looks like spoiling the language with just more quite random syntax constructions (we've already allowed various foo();, @bar {}, @baz(); :qux() {} stuff to throw yet another quux () {} in).

Counting that, I don't see how:

"For now, pretend that when() means if() and we'll get to the more advanced reasons for the name difference later."

is really more friendly than:

"For now, pretend that & when() means if() and we'll get to the more advanced reasons for the name difference later."

(Not counting that personally I'd also be very cautious with ever saying that just to safe myself from continuously saying later "In the docs they are not quite correct and when is not really something like PHP/JS if you know").

[rjgotten]

Playing devil's advocate: if you want to take syntax clarity of free-form conditional blocks to its logical conclusion, then shouldn't you instead be taking a page out of the book of @media and do:

.a {
  @when (1=1) {
    color: blue;
  }
}

Because conceptually, mixin and selector guards work exactly like @media conditions.

[matthew-dean]

@rjgotten Which was what was proposed in #2072 (along with the concept of nested @when and grouped decision trees via @select). I specifically wanted to make this issue a very narrow proposal (basically: "Can & logically be ommitted?"), and if that's not palatable, then I'll close this in favor of #2072. Although, my concern is that that discussion in #2072 ended up having a broad scope, and I don't want this piece to get lost. But, that happens. @seven-phases-max is very much against this, and you proposed my alternative syntax in #2072.

Well, technically it's not an "alternative syntax", since we were talking about @when being actually evaluated like a media query and not like & when, so the two would have slightly different uses (namely variable redefinition, which is what the issue is about).

Anyway, while it's a long / broad thread, I'll close this for #2072.