Closed saket closed 3 years ago
Yes, it was by design. From the docs:
If you don’t specify an alpha value, it will default to NaN. This makes it possible to distinguish unspecified alpha values, which can be important for operations like interpolation.
Using NaN allows the application to choose the default. That design is open for discussion, though. Is it causing problems?
It isn't a big issue, but it caught me by surprise when I tried converting my RGB
types into Color
for Compose UI -- especially because the error only shows up at runtime. The parsing logic feels inconsistent to me when I compare it with other platforms. Is there any prior art of parsing absence of alpha as NaN
on other platforms?
Yes, but I agree that it's uncommon enough that most people would be surprised, which I'd like to avoid.
So I'm thinking of two changes that wouldn't require breaking the API:
both these changes will be very welcome!
Hey @ajalt, I am replacing my custom color parsing function with
RGB(hex: String)
introduced in3.0.0
and noticed thatRGB(hex)
uses an alpha of NaN by default if the hex string doesn't explicitly specify an alpha. Was this intentional? This seems inconsistent with other platforms, atleast on android and on the web where, say,#FFFFFF
is parsed as a white with 100% alpha.