[swift-evolution] URL Literals

[David Sweeris]

> On Dec 17, 2016, at 11:15, Anton Zhilin <antonyzhilin at gmail.com> 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).

Yeah, it seems like it'd be fairly straightforward to infer a function's "pureness" for value-type arguments and variables by annotating functions like rand() and such as "@hassideeffects" (which is a very poor wording, given that we don't want the @ stuff to be camelCase). It'd be harder for reference types, since their mutating functions aren't marked as such.

We could probably get away with marking known-"bad" functions as "@whatever", use "@pure" for functions which *need* to be used that way, and let the compiler try to figure out the validity of using other, unannotated functions in a constant expression.

Yes, I'm aware this could impact compile times, but we're just talking about assigning literals here... it doesn't need to be done for every line of code, and the functions in question aren't likely to be too complex. Presumably the results would get cached along with the other incremental compilation data (I think that's the right term), as well.

Regarding terminology, there's a subtle difference between my list of constraints and what I'd normally associate with "pure" in the functional programming sense of the word... Specifically, in the FP meaning, I'd change #4 to "doesn't access any non-local variables" (which would make #1 redundant). Because of that, if this goes to a formal proposal, I prefer to use something else. "@constexpr" works for me, but I don't actually have much of an opinion on the topic, other than "@pure", IMHO, should loosely refer to code that's safely auto-parallelizable, reentrant, memoizable, etc (which is all a whole 'nother topic, but I wanted to reserve the word, so to speak).

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