One of the great benefits of generating the code for this is that we can know with much certainty at runtime that the images with those names will exist. Why not unwrap the optionals in the implementation, leaving a much cleaner API?
Images are still optional because even when we know they are there when compiling we can't be 100% sure that they are available on runtime. The most obvious example of this is on demand resource tags, an image with an tag might not be available until you request iOS to fetch te resources for you.
There also are some other edge cases where images are not available btw, but those are quite uncommon. (For example the image itself is corrupt and can't be loaded and others.)
_Note: I'll close this issue, but feel free to ask followup questions or place other comments!_
What about an option to remove optionals from generated code? While your motivations are absolutely right, cleanly checking for optionals everywhere for static resources is a pain. I suspect most users force unwrap with ! (as I do), which is even worse than cluttering the code with if let everywhere.
Since there is little chance that most static resources are missing at runtime, couldn't we guard let in generated code and fatalError() with some info about what resource is missing at runtime?
For the rare occasions where the resource could knowingly be missing, we could manually handle its loading while still benefitting from the already generated ImageResource references?
Most helpful comment
What about an option to remove optionals from generated code? While your motivations are absolutely right, cleanly checking for optionals everywhere for static resources is a pain. I suspect most users force unwrap with
!(as I do), which is even worse than cluttering the code withif leteverywhere.Since there is little chance that most static resources are missing at runtime, couldn't we
guard letin generated code andfatalError()with some info about what resource is missing at runtime?For the rare occasions where the resource could knowingly be missing, we could manually handle its loading while still benefitting from the already generated
ImageResourcereferences?