Add none to type union e.types.paint

[Mc-Zen]

This is to be discussed of course but I wonder whether it makes sense to add none to the type union e.types.paint. I think virtually everywhere in the Typst standard library, the parameter fill accepts none | color | gradient | pattern/tiling.

This makes it easier to declare fields that are to be used with native primitives like box, rect, grid, etc.

Edit: Note that stroke.paint does not accept none, however.

[PgBiel]

Yeah, stroke was my main inspiration here. I think having to write types.option(types.paint) would be fairly acceptable in such cases.

[PgBiel]

I had a similar thought regarding content vs option(content), but ultimately it all seems to have the same pattern; we'd end up adding none to more types than we need, I think.

[Mc-Zen]

Yeah, stroke was my main inspiration here. I think having to write types.option(types.paint) would be fairly acceptable in such cases.

Okay, fair point, although I think that it's the more common case that a fill also accepts none.

I had a similar thought regarding content vs option(content), but ultimately it all seems to have the same pattern; we'd end up adding none to more types than we need, I think.

However, none implicitly casts to content in Typst in most cases, right? As an example grid, highlight and all other functions that take content also take none (although not explicitly annotated in the docs). I feel like none is just some valid content.

[PgBiel]

Taking a look at the Typst source code (at https://github.com/typst/typst/blob/a4ac4e656267e718a5cf60d1e959f74b2b7346f3/crates/typst-library/src/foundations/value.rs#L658 ), that seems to be true, so we could do that change for parity, though I'm still a bit reluctant, albeit users could still use exact(content) if needed I suppose. I'll keep the issue open for now to gather more opinions before making a decision.