first-class calc

Currently this SASS

$a: 1px
$b: 2%
div
  top: $a + $b + 3em

produces an error.

But with calc in mind code above actually makes sense. It could produce

div {
  top: calc(1px + 2% + 3em);
}

Is it possible to implement this feature in SASS?

I imagine it as if calc was a literal for first-class value representing linear combination of units. So I would expect it to have properties of linear combinations, e.g.:

• you can linearly combine them with each other and other simple values
  • multiplication by number produces another calc
  • sum of calcs and other lengths is a calc
  • but trivial calcs like calc(1px) is just plain old 1px, so if in result of some computation you get trivial calc it should be reduced to plain value.
• product of calcs and other lengths should probably be an error? At least at the point of css emitting.
• optionally one can be able to access components of calc, and iterate through them. Something like extract-component(calc(1px + 1%), px) => 1 and extract-units(calc(1px + 1%)) => (px, %)

Also with all above implemented one doesn’t even need special literal for calc. Simple 1px + 1% does the trick. But it still should be there for backward compatibility, I think.

some examples:

sass expression	desired css output
10px + 10%	calc(10px + 10%)
10px + calc(1px + 2em)	calc(11px + 2em)
calc(10px + 10%) * 2	calc(20px + 20%)
calc(10px + 10%) + calc(1px + 1em)	calc(11px + 10% + 1em)
calc(10px + 10% + 1em) - 1em	calc(10px + 10%)
calc(10px + 10%) - 10px	10%

[lunelson]

FWIW I wrote a small library that does this. It implements add subtract divide and multiply functions—my solution to ‘being explicit’ about using calc—each of which can take either numeric or calc-based arguments, and which will output a new calc expression, unless the arguments are mathematically compatible, in which case it falls back to normal Sass math.

That’s basically my suggestion of how the API could work BTW, if this was integrated in to core Sass.

https://github.com/lunelson/sass-calc

[nex3]

I’m merging this into #818, since this will cover that use-case and that issue is older and has more 👍s.