Perhaps ['match'...] shouldn't require 4 arguments

[stevage]

This wasn't valid as a match expression:

                'fill-color': ['match', ['get','type'],
                    /*'park', 'lightgreen',
                    'wetland','darkgreen',
                    'school','pink',
                    'project','red',
                    'service','cyan',
                    'polder','hsla(200,70%,50%,0.3)',
                    'farm', 'hsl(60,90%,60%)',*/
                    // 'white'
                    colors.lightgreen
                    ],

That is, a match where there is only the default value (everything else was temporarily commented out). It seems legitimate by analogy with:

switch(x) {
  default: f()
}

[asheemmamoowala]

@stevage Can you describe your use case for wanting this behavior with the match operator? It can be supported, but it is not clear to me what the value of this would be, compared to the complexity of providing such a no-branches fallback.

[stevage]

No use case here. If it's any harder to implement than changing a 4 to a 2, it's probably not worth it.

[mourner]

There was an attempt at fixing this at #6964, which we punted on — see discussion on the reasons there.

[mvirkkunen]

@asheemmamoowala I actually have a usecase where I needed this. I'm generating a "match" from other data, and in one case that other data resulted in no cases. It was very surprising that this caused an error, because there was still the "fallback" value. Caused a bug in production.

The same probably applies to "case" and perhaps other things too.

@mourner That issue was describing a different usecase, where the last value was a label not a fallback value.

[stevage]

@mvirkkunen Ah yes, I have run into that situation as well. I think similar issues arise sometimes when you end up with an expression like ['any'] etc.