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 < [email protected]>: 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
