Repository navigation
Early opt out behavior for @mixin #4262
Description
Problem
@mixin currently does not support an early opt-out mechanism.
This can result in code that is harder to follow, or harder to write, as either more nesting or more variables are needed.
Simply put, it adds cognitive complexity that an early opt-out could avoid.
In simple use cases (like the one I posted below) this seems to matter little, but I would argue that even there it already has benefits.
For larger blocks with more conditions this can ramp up the cognitive complexity rapidly.
Nesting Example
@mixin render-non-accessible-icon($icon) {
@if $icon != null and $icon != "" {
@if meta.type-of($icon) != "string" {
@error "`$icon` should be a string.";
}
content : $icon;
content : $icon / "";
}
}Variable Example
@mixin render-non-accessible-icon($icon) {
$has-value : ($icon != null and $icon != "");
@if $has-value and meta.type-of($icon) != "string" {
@error "`$icon` should be a string.";
}
@if $has-value {
content : $icon;
content : $icon / "";
}
}Proposal
@mixin render-non-accessible-icon($icon) {
@if $icon == null or $icon == "" {
@return;
}
@if meta.type-of($icon) != "string" {
@error "`$icon` should be a string.";
}
content : $icon;
content : $icon / "";
}When @return is reached, all properties / code before it is still rendered and executed, and everything after it is skipped.
Why @return
@returnis currently already used by@function, so people are already familiar with the keyword and its functionality.- It mimics a known pattern from other languages like JS, Java, C#, etc.
- No backwards compatibility issues, as
@returninside a@mixincurrently throws a compile error.
That being said, I'm not married to the @return keyword.
Related issues
These are some issues I've found, which seem tangentially related:
- no support for break or continue in loops #378
Related, as here they also ask for an exit keyword, only for loops instead. - First-class mixins #3439
This issue is mainly about something else, but the@mixinthere would have benefited from an@return, reducing complexity. - Is there any return value from @mixin? #2686
Seems the same, but here they are asking for a return value, which I do NOT want.
Activity
nex3 commentedon Oct 28, 2026
I think this is a reasonable feature. The main question I have is whether
@returnor@breakis the appropriate at-rule here.@return, as you say, mirrors other languages in the sense that mixin is analogous to a void function, but it does carry the implication of a return value which isn't accurate here.@breakwould be more literally accurate to the intention of "end execution immediately", but it has the disadvantage that it would break the innermost loop rather than the mixin as a whole if used in a nested context. I'm open to hearing arguments either way.cduivis commentedon Oct 30, 2026
Between those 2 I would argue for
@returnstill, mainly because of the point you already made for being able to also "escape" the mixin in deeper nested contexts.In that way you keep open that possibility for when implementing #387 with
@continueand@break, or if you would want to add an@switch@casewith@break.As for the wording I think both work fine
@breakas in "stop what your are doing now", but also@returnas in "return to the code you came from".The benefit
@returnhas over@breakfrom a conceptual point of view is that it's then consistently used in both@functionand in@mixinto completely step out of the context of the "executable context", where@breakis then consistently used to step out of smaller control flows.I also think keeping these naming conventions in sync with older languages, is a benefit for adopting / learning sass quicker as it's the same terminology as lets say JS, which is probably a language a person who would write more complex sass mixins and functions is already familiar with. Although I wouldn't want to rely on this reasoning in all use cases.