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

Go over std and core and add pure declarations #1315

Closed
boggle opened this issue Dec 16, 2011 · 12 comments
Closed

Go over std and core and add pure declarations #1315

boggle opened this issue Dec 16, 2011 · 12 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@boggle
Copy link
Contributor

boggle commented Dec 16, 2011

Noticed some fns in std and core could be annotated as pure. This should be done so that they may be used from predicates.

This probably needs to happen twice, once now and once later, after mutation of local variables is possible in pure functions. It would also help if there could be pure blocks.

graydon added a commit that referenced this issue Dec 16, 2011
fix to #1315 + small additions to std::either and result
@kud1ing
Copy link

kud1ing commented Jan 4, 2012

I've opened #1422 because i could not find a related issue.

@brson
Copy link
Contributor

brson commented Mar 15, 2012

I did another pass. I guess we're waiting on #1422 to close this.

@ghost ghost assigned catamorphism Apr 12, 2012
@catamorphism
Copy link
Contributor

Let's not do this immediately, given that some reflection on purity checking / typestate in general is still pending. (See #2178)

@kud1ing
Copy link

kud1ing commented May 14, 2012

Since #1422 is now implemented, maybe it's time for another round off pure-adding?
Since i'm moving, i won't have inet for some days ...

@catamorphism
Copy link
Contributor

Okay -- I'm still hesitant, as there is a certain amount of unresolved fear and uncertainty about typestate, but I guess it won't take too much time to do a quick go-round.

@kud1ing
Copy link

kud1ing commented May 14, 2012

I mostly think of str::count_* et al. Not sure how typestate interfers there.

@catamorphism
Copy link
Contributor

It doesn't interfere -- it's just that pure declarations are only useful for the typestate analysis. If typestate got removed, it wouldn't be necessary (that's what I mean about the fear and uncertainty: about whether Rust should have typestate with arbitrary predicates, not about whether typestate works or not). So the concern is that adding pure declarations could be a waste of work. Then again, maybe I've just wasted more time hemming and hawing about it :-)

@kud1ing
Copy link

kud1ing commented May 14, 2012

Couldn't the current pure declarations be ported to whatever replaces pure?

@catamorphism
Copy link
Contributor

It's not a question of replacing pure, it's a question of whether the whole concept of distinguishing between pure and impure functions will be abandoned entirely, since no other pass besides typestate uses it, and typestate may be eliminated entirely.

@kud1ing
Copy link

kud1ing commented May 14, 2012

I understood pcwalton's comment in #2178 as Typestate won't be eliminated ever.

I think pure functions are very important for documenting code and making code secure/reliable.
Are the upsides/downsides of that removal documented anywhere?

@catamorphism
Copy link
Contributor

I understood his comment as saying that typestate won't be eliminated when it comes to checking definite-assignment, but that the question of whether typestate predicates with arbitrary user-defined functions will be eliminated or not is still open. Of course, I may have misunderstood...

No, I don't know of anyplace where the upsides/downsides of removing them are documented. As far as I know (but I wasn't here from the beginning, so I may have missed some stuff), pure annotations have always been around as a somewhat unfortunate requirement for typestate (since inferring purity in general is undecidable, and inferring a conservative subset of pure functions would lead to unpredictable results). While they might, unintentionally, have other purposes (like documentation), that wasn't the intent of adding them to the language.

@catamorphism
Copy link
Contributor

I don't feel like this is so relevant anymore now that typestate is gone. It can be done lazily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

4 participants