Re: [rust-dev] Purity by default

[Niko Matsakis]

Patrick— I think what you're saying -1 on here is some kind of purity inference?  That doesn't seem to be what was proposed, though. In fact, I *believe* Nathan's point was merely that it's useful sometimes to document "purity" in order to express the intention of the API, and that in those cases it's nice to write it explicitly, just as it's nice to have the types of parameters and return types written explicitly.  This does not seem to be in disagreement with what you said about reserving the right to become impure. Niko Patrick Walton October 24, 2012 11:58 AM -1 on this. I think that it's often quite useful to reserve the right to make a presently-pure function impure later without breaking callers. When commenting out code, for example. Patrick _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Nathan October 24, 2012 10:51 AM On Wed, Oct 24, 2012 at 9:49 AM, Niko Matsakis <n...@alum.mit.edu> wrote: It's an interesting question.  I am not sure whether "most" functions can be pure under the definition I gave in that blog post, but likely a great many.  There is also some question of whether we should have purity at all.  pcwalton and I have been thinking about an alternative which would allow us to remove the pure qualifier altogether, though unfortunately it's less expressive.  The basic idea is that instead of requiring purity, the borrow checker would only permit calls to functions that cannot access mutable state.  This can be guaranteed through a combination of a Const bound and by checking the types of values provided as a parameter.  This has the advantage that all fn items fit this definition, presuming that their parameters are of appropriate type. The value of the "pure" keyword is not only in the static checking, but also in the programmer documenting the intention of their API.  When both of these benefits are tied together, the documentation benefit has much more value. In fact, there's a close parallel between purity inference and type inference, since we can think of purity as an aspect of the type.  So even though we have type inference, it is very useful to see type annotations when looking at APIs. Therefore I'd propose that the purity keyword must be present and match the purity inference in every context where a type signature must be present to match the type inference. I hope to get around to writing this up as a blog post trying to explore the areas where the newer approach would fall short of purity. Niko Regards, Nathan Wilcox Stefan Plantikow October 24, 2012 12:28 AM I like that idea very much except that there are probably situations in which one wants the reverse, i.e. modules marked as impure which then requires purity annotations for functions. boggle. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Jesse Ruderman October 23, 2012 7:49 PM Should functions default to pure? * With http://smallcultfollowing.com/babysteps/blog/2012/10/12/extending-the-definition-of-purity-in-rust/ I think most functions will be able to be pure. * Would avoid the problem of forgetting to mark a function as pure, causing pain for a caller. (Or worse, causing the compiler to generate slower code?) * Would encourage writing pure code, by making pure less typing than impure. * With http://smallcultfollowing.com/babysteps/blog/2012/10/23/function-and-object-types/ the "impure" and "unsafe" modifiers would move in the same direction. (Currently, "pure" and "unsafe" move in opposite directions from the default, which is impure.) _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Stefan Plantikow October 23, 2012 11:28 PM I like that idea very much except that there are probably situations in which one wants the reverse, i.e. modules marked as impure which then requires purity annotations for functions. boggle. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Jesse Ruderman October 23, 2012 7:49 PM Should functions default to pure? * With http://smallcultfollowing.com/babysteps/blog/2012/10/12/extending-the-definition-of-purity-in-rust/ I think most functions will be able to be pure. * Would avoid the problem of forgetting to mark a function as pure, causing pain for a caller. (Or worse, causing the compiler to generate slower code?) * Would encourage writing pure code, by making pure less typing than impure. * With http://smallcultfollowing.com/babysteps/blog/2012/10/23/function-and-object-types/ the "impure" and "unsafe" modifiers would move in the same direction. (Currently, "pure" and "unsafe" move in opposite directions from the default, which is impure.) _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev