[swift-evolution] URL Literals

[Anton Zhilin]

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).

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161217/fe2a89b5/attachment.html>