Can we simplify a variable with ruleset value (aka DR) declaration?

[seven-phases-max]

The propose is to allow omitting the terminal ; in:

@var: { 
  key: value
}; // currently requires semi-colon after final brace

[seven-phases-max]

currently requires semi-colon after final brace but may become optional for detached rulesets

There's hidden [decision needed] for "No ; in the end". The following declaration:

@var: {...} foo {...}

can be interpreted either as "DR decl. followed by foo ruleset" or as "DR foo DR" list. So while an intention to clean-up the syntax is understandable, it's worths to mention that it will kill a possibility to define a list of DRs or similar things (maybe it's a minor use-case but still).
Curiously in similar case https://tabatkins.github.io/specs/css-apply-rule/, he also decided to require ;.
Thinking of it more, indeed, if we treat properties as variables too (for example to be accessed with ns[nested-dr]) and finally allow something like:

@dr: { // or #ns() 
    nested-dr: {...}
    another-dr: {...}
}

it also becomes quite ambiguous to detect if another-dr is a property or just a broken selector.

---

Personally I'm not quite sure if me is +1 or -1. ; indeed is somewhat visually annoying and confusing there, but in the same time I do not want to loose some extra possibilities in future. (Also related less/less.js#2270 (comment)).

[matthew-dean]

Part of my thinking is the discussions to align DRs and mixins a bit more (the latter of which does not need a semicolon after its ruleset). Not just that, but nowhere else in Less / CSS does associating a ruleset with a node require either a colon or a terminating semi-colon after the closing brace. The closing brace is always the end of that node everywhere else in the language. Such that when using rulesets, I get errors for omitting a semi-colon after the final brace constantly, so it's a personal pet peeve.

As to:
a) preventing a list of DRs. That's both... kind of weird to have a list of them, but also not without a workaround (assigning to a var first). It wouldn't be the only instance where assignment to a var is required (such as calculated expressions within strings or other interpolation).

b) assigning to a property - I don't see the need, nor limiting. The reason for referencing properties is to use their values in other calculations, but the given use case is for valid properties. Yes, properties can be hackable when we allow referencing beyond standard CSS properties, but we don't have to design a verbose syntax around a specific type of non-designed hackability that has a bunch of workarounds to do the same thing.

In CSS, a ruleset is an implied closing ;, so while they're needed for variable assignments (which model rules, which need them), DRs model ruleset syntax, other than the assignment of that ruleset to a variable. So to me, the ; here feels like a syntax mistake. For some who might think it feels more natural, the compromise to me would be to allow it to be optional.

[seven-phases-max]

Just a remark for:

So to me, the ; here feels like a syntax mistake.

It can't be because the syntax is not even invented (the invented syntax is: *call(..., {...}); w/o any ; after the ruleset), thus:

Not just that, but nowhere else in Less / CSS does associating a ruleset with a node require either a colon or a terminating semi-colon after the closing brace.

That's the trick. ; is the part of variable definition statement not the part of ruleset at all. Thus if we change @var: {...}; variable definition statement to @var: {...} we simply introduce/invent a new kind of statement.

---

This is not to say "we don't need this", but to only clarify why "CSS rulesets and mixins don't need ;, but @var: {...};syntax does"). Technically it's not of course a problem for the parser to pretend it's got its ; after the last matching } (just like it does for any property or variable before the first non-matching {).

[matthew-dean]

That's the trick. ; is the part of variable definition statement not the part of ruleset at all.

Actually, it's part of neither. It's a statement terminator, and in CSS, as you say, some statements can have an implied termination, such as the end of a block.

But I know what you're trying to say, which is that the ruleset is the value assigned to the variable; therefore it follows variable syntax. Sure, yes, BUT, it feels like this to me:

.mixin           // identifier
{                // start of block associated with identifier
  prop: val;     // rules
}                // termination of both block and statement (statement being associating identifier with block)

@dr:             // variable identifier with explicit assignment char
{                // start of block associated with identifier
  prop: val;     // rules
}                // termination of block
;                // termination of statement

Not that Less could necessarily parse those newlines, but I see those identifier / blocks as comparative.

[matthew-dean]

Just to address rulesets as lists, there are other cases where we require assignment to a var first, so you could do:

@dr1: {
  prop1: foo;
}
@dr2: {
  prop2: foo;
}
@dr-list: @dr1 @dr2;
.some-mixin(@dr-list);

Seems like a small requirement for that use case, which is probably an edge case.