[swift-evolution] Idea: "pure" keyword for function signatures
Xiaodi Wu
xiaodi.wu at gmail.com
Thu May 25 17:57:13 CDT 2017
This is a topic of considerable history. See:
https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20151214/003684.html
https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20151221/003900.html
https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20160104/006005.html
https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20160905/027010.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032076.html
It would be important for those who wish to rekindle this discussion first
to review and summarize the preceding, and very technically illuminating,
discussions.
On Thu, May 25, 2017 at 5:39 PM, Michael Savich via swift-evolution <
swift-evolution at swift.org> wrote:
> Writing functions without side effects is generally considered to result
> in less error-prone code. In Swift today, if you want to segment your code
> into pure and impure functions, you just have to police yourself, which is
> a very un-Swifty thing to have to do. This problem is compounded when
> working in teams, where someone else of course won’t know which of your
> functions are pure, and even if you leave a comment it’s not a guarantee
> they’ll know (or care) what “pure” means.
>
> So what about adding the ability to annotate functions with a special
> keyword? For example "pure func addTwoNums(n1: Int, n2: Int)”.
> The rule here is very simple: functions annotated with “pure” can only
> call other functions annotated with “pure”, otherwise the compiler produces
> an error.
>
> To me, this feels like a very natural fit for Swift. What does everybody
> else think?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170525/7208f168/attachment.html>
More information about the swift-evolution
mailing list