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

Stabilization #23

Closed
Marwes opened this issue Mar 22, 2015 · 1 comment
Closed

Stabilization #23

Marwes opened this issue Mar 22, 2015 · 1 comment

Comments

@Marwes
Copy link
Owner

Marwes commented Mar 22, 2015

Currently nothing in the library has any stability attributes set which will be a problem once stable rust starts to roll out. For the high level API (thinking about function names and what their purpose are) I feel that it is mostly stable enough that I could commit to the design for a 1.0 so to speak. The lower level details are more prone to change however.

  • The SourcePosition type is likely going to be made generic in some way. Currently though, the easiest/least intrusive design is currently blocked by Trait bounds are not yet enforced in type definitions rust-lang/rust#21903.
  • It is unlikely but I might want to change the signature of the parse functions to take the state by &mut instead. Currently this alternate design is both slower and less intuitive but when attempting to optimize the error creation I needed some additional state struct State which evidently made the struct large enough that passing by reference would be beneficial. Since I only achieved around 40% speedup I am not convinced that the added complexity makes it worth it.

If nothing changes between now and the release of rust 1.0 that makes me able implement these changes I will likely stabilize what is here now and probably integrate these changes into a potential 2.0 version instead.

fn parse(&mut self, input: &mut State<I>) -> Result<Output, Consumed<Error>>
@Marwes
Copy link
Owner Author

Marwes commented Aug 2, 2015

Point 1 is done by adding the Positioner trait.
Point 2 won't happen for 1.0 at least as it would break to much code and complicates the API.

Closing.

@Marwes Marwes closed this as completed Aug 2, 2015
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

1 participant