[Calc Functions] Update based on implementation feedback #3675
Conversation
|
With this new merged syntax, how is it expected to interact with the /-as-division deprecation ? In particular with the expected future state where |
`round($number: 1px)` should _always_ be evaluated as a function call.
|
Good question. The same syntax would still parse, so the main issue is one of precedence—a |
nex3
force-pushed
the
calc-functions.slash
branch
from
e415792 to
54e7d35
Compare
| `"round"`, or `"abs"`; and all arguments in `call`'s `ArgumentInvocation` are | ||
| [calculation-safe], return the result of evaluating `call` [as a calculation]. | ||
| `"round"`, or `"abs"`; `call`'s `ArgumentInvocation` doesn't have any | ||
| `KeywordArgument`s or `RestArgument`s; and all arguments in `call`'s |
There was a problem hiding this comment.
Should this keyword/rest condition apply to the other calc functions too? or why is it that only these four get this special behavior?
There was a problem hiding this comment.
These four get special behavior because they'll fall back to calling global Sass functions. For the others, we want keywords and rest arguments to be errors instead—if we exempted calls that included them, rest arguments would just be passed to plain CSS functions, so something like clamp(1 2 3...) would return the unquoted string "clamp(1, 2, 3)" instead of producing an error. I'll add a note to explain this.
|
|
||
| * If `result` is not an unquoted string, throw an error. | ||
| * If `result` begins case-insensitively with `"var("`, or if `expression` is an |
There was a problem hiding this comment.
Currently calc(1 / #{2 / 5}) results in calc(1/2/5) which evaluates to 0.1.
IIUC this change means that it'll now produce calc(1/(2/5)) which evaluates to 2.5.
Is that correct?
There was a problem hiding this comment.
No. These are the semantics for evaluating a ParenthesizedExpression, and calc(1 / #{2 / 5}) doesn't contain a parenthesized expression. It would only produce calc(1 / (2 / 5)) if you wrote calc(1 / (#{2 / 5})).
accepted/calc-functions.md
Outdated
| > For example, if we insert virtual parentheses to explicitly indicate | ||
| > precedence groupings, `(1 + 2) / (3 + 4)` becomes `1 + (2 / 3) + 4`. |
There was a problem hiding this comment.
IIUC the user input here is 1 + 2 / 3 + 4, but the parser reads it like slash_list(1+2, 3+4), and this process changes it to 1 + slash_list(2,3) + 4. right?
If so, I think that even though you mention "virtual parentheses" (TIL -is is singular and -es is plural!) it's confusing to see "(1 + 2) / (3 + 4) becomes 1 + (2 / 3) + 4". Like I can understand it, but it takes me a couple reading passes.
There was a problem hiding this comment.
Updated to use slash-list notation.
nex3
changed the title
| > For calculation functions that overlap with global Sass function names, we | ||
| > want anything Sass-specific like this to end up calling the Sass function. | ||
| > For all other calculation functions, we want those constructs to throw an | ||
| > error (which they do when evaluating `call` [as a calculation]). |
See #3504