Support maps in list context (index, nth, etc)

[madlandproject]

Example file, sasstest.scss :

$test-map : (
        mykey    : 10px,
        otherKey : 20px,
        moarKey  : 30px
);


@mixin testMixin($key-name) {

  // get index in map
  $item-value : map-get($test-map, $key-name);
  $item-index : index($test-map, ($key-name $item-value) );

  @debug $item-index;

}

@include testMixin(otherKey);

Expected output (using ruby sass 3.4.21) :
sasstest.scss:14 DEBUG: 2

Output with libsass :
sasstest.scss:14 DEBUG: null

[mgreter]

I do see the difference, but wonder if this is actually indended behavior. IMHO this is quite a "funky" feature so to speak (never seen any similar "index" function with "hash-maps") //CC @chriseppstein

$test-map : (
  key : 20px,
);

foo {
  bar: index($test-map, ("key" 20px) );
  baz: index($test-map, ("key", 20px) );
  ibar: inspect(index($test-map, ("key" 20px) )); // 1
  ibaz: inspect(index($test-map, ("key", 20px) )); // null
}

Yields in ruby sass:

foo {
  bar: 1;
  ibar: 1;
  ibaz: null; }

[xzyfer]

For context, when a map is used with index (instead of a list) it's treated a list of lists. i.e. (foo: bar, bar: baz), is (foo bar, bar baz).

This applies for all list functions. This is documented in the Sass changelog for 3.3.

All the existing list functions also work on maps, treating them as lists of pairs. For example, nth((foo: 1, bar: 2), 1) returns foo 1. Maps can also be used with @each, using the new multiple assignment feature (see below):
source

[mgreter]

Would be great if someone could come up with a complete list, or better spec test suite for all related functions, since this doesn't seem to be related to index only (I don't think nth has that support)!?

[mgreter]

On another note this should probably be connected to a refactoring with selector lists, since all three types seem to share some common properties (iterable etc). Would probably help we had this covered in AST directly and not having to implement the logic again in each function (nth, inspect, etc).

One of the main issues with lists is that we sometimes have nested lists (specially in regard to functions arguments). Selector_Lists became IMO quite stable during the recent refactorings for selector functions and parent selector handling. But there is also a big potential for further refactorings. And I'm really not sure if the initial design for Complex, Compound, Simple selector was such a great design. I don't mean the types per se, but how it is handled with head and tail as the approach Node class has with a list of simple selectors and combinators seems more natural to me. Not sure where the linked list approach with tail has it's strength (probably visitor pattern), but it certainly is not manipulation.

[chriseppstein]

Sass maps are ordered. As such, the pairs within them have an intrinsic index based on insertion order.

[saper]

Ouch. So we need to implement them as the list of (k,v) items, never the hash map...

[mgreter]

We already currently implement them as std::unordered_map, but not sure what performance implications are for indexed access (when changed to ordered map). In the worst case we have to keep an additional vector, but I guess that's pretty much how std::map is implemented in the first place.

Edit: sorry, I though it was an ordered map. I changed that one once, but we can easily go back to an ordered map. We "just" need to implement the indexed access in libsass functions.

Amend: from a short check it seems that we need to add a vector deque to our map object to support fast indexed access. Not super nice to add the memory overhead, but also not very hard to implement.