[swift-evolution] URL Literals

[David Sweeris]

> On Dec 19, 2016, at 11:55 AM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 19, 2016, at 11:48 AM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto: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.

I want to elaborate on this a bit… While both of my ideas might (depending on what all can be marked @constexpr) allow someone to check whether an URL actually points to something at compile-time, in all my examples, I was only intending to check that the URL in question was syntactically valid, not whether accessing it would result in some sort of “not found” error. You’d still have to check at runtime that the server is up & responding, that the file is still where you think it is, etc. However, if someone wants to expressly make it a syntax error to compile their code while “www.my.hardcoded.site.com” is down for maintenance, their internet connection is spotty, or whatever... Well… I can’t fathom why that’d be a good idea, but IMHO the pros of being able to get compile-time validation of literals far out-ways the downside of giving people one more opportunity to write some “questionable” code.

Actually, I just thought of one kinda-sorta-not really potentially valid use… In a group environment, it could be used to check that a SVC server is up, as a guard against trying to work with out-dated code. Personally, I think that’s the wrong solution to that particular “problem" (to the extent that it is one), but it is a solution (sorta), and I don’t think I can confidently say that it’s impossible for something like that to be the right decision for someone else. (Yes, it’s a real stretch… I know… the point is that in the amount of time it took me to write one paragraph, I went from “this would never be a good idea”, to “eh… this would probably never be a good idea”. Given more time to think on the possibilities, perhaps someone will think of something really cool and useful to do with it.)

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161219/45449202/attachment.html>