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