You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add common "functional" functions to iterable objects SASS.
There are several functions of this class that could be added and would provide significant benefit. E.g.
map
filter
reduce
Use Case
When writing sass, I find that I spend a significant amount of time writing things that look like:
I'm going to mark this as a duplicate of #472. Higher-order functions like map() and filter() don't really make sense without the ability to write anonymous functions, and if we added anonymous functions we'd definitely add library functions that supported them.
This is difficult for a number of reasons, though. Anonymous functions are syntactically and semantically complex, especially for a userbase that is often coming from a pure CSS background and unfamiliar with more general-purpose programming languages. At the same time, because Sass is not general-purpose, the set of circumstances where these features are applicable is narrower than in other languages. It's not a priori clear to me that this feature would pull its weight, especially if we consider alternatives like a dedicated list comprehension syntax.
Proposal
Add common "functional" functions to iterable objects SASS.
There are several functions of this class that could be added and would provide significant benefit. E.g.
map
filter
reduce
Use Case
When writing sass, I find that I spend a significant amount of time writing things that look like:
This common structure is often known as "map" in many functional languages.
In an ideal world I'd write something like:
Side notes
There are some odd language semantics here (lambdas), that I've not yet seen in SASS, but may be possible (first class functions).
Additionally, if SASS could support anonymous lambdas (probably difficult), that may also be cool.
Edge cases
There's also probably some edge cases around providing values that are not args to the callback as values inside the callback function.
The text was updated successfully, but these errors were encountered: