Yes, so this option sucks.

I wonder if that's something that should go in #C0B9K7EP2 or even KEEP

I don't know if it really makes sense 🙂

It's possible to do some trickery with a delegate so you can write:

backgroundColor: Color.RED

backgroundColor: Color.BLUE

It might not be too bad. Internally it would just be a list

They would be added in the order they were assigned.

You're right, it might actually make sense 🙂

The problem with that would be the get for backgroundColor expects a paint to be returned.

Really, vararg properties would just be syntactic sugar for using lists, much like varargs are for functions

It can just return Color.TRANSPARENT or something, we'd get the real list from a backing property.

Internally it would be fine. It would just be a problem if the user wants to get the value.

Yeah..

A new property called

backgroundColors

is another option.

Color.TRANSPARENT could work, but it could be confusing to the user (there's isn't a reason it should return transparent, as the result isn't actually transparent).

But it's far from ideal.

I thought of that too, but that would lead to the same getting problems. If I set something with

backgroundColors

(being a list of Paints) and then get

backgroundColor

, it would try to convert the list to a Paint.

backgroundColor

could return the first in the list. But still not intuitive.

I also thought of creating a

backgroundColors

property that maps to a different key in the map, but is converted to the correct output, but then you run into an issue with priority.

Honestly, I think the cleanest solution would be to always expect an array from the user, and include a convenience function for a singleton array.

That would create a breaking change though

Every time you assign to

backgroundColor

, a new value could be added to

backgroundColors

. Getting

backgroundColor

could return the last entry in

backgroundColors

?

Not many people have started using it, and changing the code would be trivial.

What if you want to override

backgroundColor

instead of adding to it?

Why would you want to really? 🙂

I'm not sure. I'm just thinking through all possible outcomes 🙂

The cleanest solution by far is to remove backgroundColor and introduce backgroundColors.

But writing

backgroundColors: listOf(Color.RED)

isn't as sexy 🙂

It's not super annoying though.