I might(?) agree with others that `constexpr` might overlap but be ultimately different from `pure`. However, to me `constexpr` is more interesting because it would provide a potential macro language.
As for syntax, while I think that matters less, I suspect trying to find why code isn't working and having to find a "->" vs. "=>" might be difficult. As for the pure aspect, couldn't that compiler just look at the arguments and determine that the function has no side effects? The only complication comes when its a method to a class. However, something like the c++ notation of: int bar() const { ... } could be used. However, it might be more Swiftly to do something like: const func bar() -> int { ... } as others have suggested. This would make many non-member functions automatically get made into purely-functional forms (with potential optimizations). You should be able to do the same thing with type methods (static/class). On Fri, Feb 17, 2017 at 11:18 AM, Anton Zhilin <antonyzhi...@gmail.com> wrote: > I didn’t mean to emphasize any specific syntax. I’m fine with either @const, > @constexpr, @pure or =>. > Anyway, I see no reason why generic functions shouldn’t be supported in any > of the suggested models. > > 2017-02-17 19:08 GMT+03:00 Abe Schneider <abe.schnei...@gmail.com>: >> >> +1. I think this is a great idea. As I was following this thread, I >> was wondering if someone might suggest the C++ constexpr syntax. >> >> Would this support generics? E.g. could you do: >> >> @constepxr >> func foo<S>(a:S, b:S) { >> return a+b >> } >> >> and have that be done at compile time? While this could potentially >> add a huge amount of complication on the backend, I could this as >> being useful (also related to my previous postings as to having a way >> of determining generic types at compile time). _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution