[swift-evolution] URL Literals

[Xiaodi Wu]

The behavior is not altogether clear to me either. Since XCode does show a
preview of images, it's fair to think that there's some sort of
compile-time validation going on.

I would not be opposed to image and file literals changing their behavior
so that when a user drags a file into the IDE the file contents are what
are embedded via a data URL, rather than a file path. I do know that in a
Playground, when you choose a file for a file literal, an alias is made to
that file stored in a different folder for Playground resources, and it's
that alias which is referenced in the resulting URL. This seems brittle to
me.

On Mon, Dec 19, 2016 at 13:55 David Sweeris <davesweeris at mac.com> wrote:

>
> On Dec 19, 2016, at 11:48 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> Ah, ok, I didn’t realize that image literals weren’t actually created
> until runtime... In that case, I retract my statement that they shouldn't
> be any different, because they while they both may be called “literals",
> they use that word to mean to two quite different things.
>
> - Dave Sweeris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161219/5c5c0b52/attachment.html>