[swift-evolution] URL Literals

Xiaodi Wu xiaodi.wu at gmail.com
Mon Dec 19 13:48:41 CST 2016


On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> ```swift
> let x = #imageLiteral(resourceName:"nothere.jpg")
> print(x)
> ```
>
> This compiles. It crashes at runtime. I don't see why URLs should be any
> different.
>
> — E
>
>
> They shouldn’t be. The print function can already handle things that
> aren’t `CustomStringConvertible`:
>
> struct Foo {}
> let x = Foo()
> Foo.self is CustomStringConvertible //says `false`
> print(x) //says `"Foo()\n"`
>
> so, IMHO, that’s a bug.
>
>
> Oh, hey, wait a second… I didn’t catch the meaning of the resource name,
> and thought you meant it was crashing on the print statement. I still think
> it’s a bug, because the compiler should be able to check if the resource
> exists.
>

I think the point here is that what exists at compile time may not exist at
runtime and vice versa, so while a warning might be elegant, it's not
helpful for the compiler to refuse to proceed on the basis that the image
does not yet exist. At the end of the day, an image literal hardcodes the
path to an image, not the image itself. Whether it ought to is another
kettle of fish.


> - Dave Sweeris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161219/d3f08090/attachment.html>


More information about the swift-evolution mailing list