Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the pure keyword #2753

Closed
brson opened this issue Jun 29, 2012 · 5 comments
Closed

Change the pure keyword #2753

brson opened this issue Jun 29, 2012 · 5 comments

Comments

@brson
Copy link
Contributor

brson commented Jun 29, 2012

It's not obvious what pure means in rust, but it doesn't seem to have much to do with common notions of purity.

For example, pure functions can call stateful closures.

@catamorphism
Copy link
Contributor

Just to elaborate, "pure" means "as pure as the borrow check needs a pure function to be"... which is a weaker notion than referential transparency, and isn't the same kind of "pure" that typestate would want either.

@kud1ing
Copy link

kud1ing commented Jun 29, 2012

I was surprised to learn that vec::append*() are marked pure while effectively altering the lhs (after overtaking ownership).
That's more like D's "weak purity" than Haskell's purity: http://leonardo-m.livejournal.com/99194.html

@nikomatsakis
Copy link
Contributor

I am not persuaded that a new keyword is needed. Pure means that the function itself does not make changes to data it does not own. We have a slight generalization because we allow the function to invoke closures that are given as arguments, so in fact a function declared as a pure is parametrically, or conditionally, pure---"as pure as the closures it is given as arguments".

@catamorphism is correct though that this is insufficiently strict for typestate. To be correct, typestate must prohibit reads from non-owned, mutable state. (Also, of course, for a type state predicate to be considered pure it is not enough that it calls a pure function, it must also not supply only pure closures as arguments)

@catamorphism
Copy link
Contributor

Two points from discussion on IRC: 1. It seems like "does not make changes to data it does not own" does amount to referentially transparent, as long as all higher-order function arguments are also referentially transparent (conditionally pure, as @nikomatsakis says). But this is fairly subtle and should be documented, or else people are going to look at a function and ask "how can this be pure, it mutates data?!" 2. The "conditionally pure" part is probably the most confusing thing. I'm not sure most people think "pure" means "as pure as its arguments". So I'm still in favor of changing the keyword.

@catamorphism
Copy link
Contributor

There doesn't seem to be much interest in changing the keyword, and now that we no longer have typestate we no longer have the motivating reason that there are two notions of purity. So I'm closing.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants