[swift-evolution] URL Literals

[Micah Hainline]

So here are some thoughts. I like the idea of an annotation for compile-time validation, though I haven't given up on simple #url yet either. For the people interested in @pure for its implications for functional programming, I'm questioning if that concept sufficiently limits the problem when you're talking about compilation. I'm a little worried about things like cyclical references--not knowing if one class compiles until you've run code from another class, or even another library. Is it clear that the concept of @pure is sufficient for this?

I FEEL like this is opening the door too far, at least a little.

If we did do something like this as more than a one-off for URL however the external API looks we still would need to talk about the internal mechanics of how something can be marked as a compile error. Is it something like a special throw happening inside the code? Is there a precompiler-type directive denoting code that executes inside the block happens only at compile time?

I'd love a fleshed out elegant example for URL that shows what a complete implementation of that special init method would look like. 

> On Dec 17, 2016, at 1:15 PM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I was in the process of writing something along those lines :)
> 
> But I would prefer this attribute to be added implicitly by the compiler.
> Then, if we want to validate that some function is statically computable, we add @pure to the function.
> If we want to require that some variable is computed at compilation time (even if it takes a lot of time, even in debug builds), we add @pure to the declaration.
> 
> 2016-12-17 21:59 GMT+03:00 David Sweeris via swift-evolution <swift-evolution at swift.org>:
> 
>> It wouldn't have to be restricted to a subset of the language; just to functions whose evaluation doesn't depend on anything that happens at runtime.
>> 
>> Any "@pure" (or whatever... it's easier to type on my phone than "@constantExpression") function should work fine, if we define a "pure" function to be something like:
>> 1) Doesn't mutate anything outside its own scope
>> 2) Doesn't call anything involving rand() or other non-deterministic functions
>> 3) Doesn't have a result that depends on the host or target architectures (I'm not sure if this extends to FP subtleties)
>> 4) Doesn't reference any non-local variables which don't themselves have a value that's either itself a literal or the result of evaluating a "pure" function
>> 5) Doesn't call any other functions which aren't themselves "pure", or instantiate any variables using inits that aren't "pure"
>> 
>> Since there's already a Swift REPL, at least conceptually speaking, this doesn't seem too hard (although it does raise the bar a bit for what it takes to have a "full" Swift compiler, since it'd then depend on having a working REPL on the host platform, which IIRC wasn't the case on Linux for a while... dunno, maybe this is a non-issue).
> 
> _______________________________________________
> 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/20161217/e3d39a67/attachment.html>