On Wed, Oct 24, 2012 at 9:49 AM, Niko Matsakis <[email protected]> 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 <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > Jesse Ruderman <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
<<compose-unknown-contact.jpg>>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
