Comments (3)
So... why a separate crate? The Visitor
trait is going to be deeply intertwined with the structures created in this crate and will need to be updated when names and children change. In addition, if you want to keep the feature flags, then those would need to be reflected in both crates, I'd believe.
from syn.
Yeah you're right. I've come around on this. Same reasoning as for fold
(#43):
I am hesitant to pile more features into syn because if an optional feature requires a breaking change, even people not using that feature suffer from the version bump. With a relatively stable core in syn and an ecosystem of supporting libraries around it, you are only affected by breaking changes to pieces that you use.
I guess
fold
is core enough and coupled so closely with everything else in syn that the scenario of breakingfold
without breaking syn seems unlikely, so you're right it could make sense to implement here rather than a separate crate.
from syn.
Fixed in #79.
from syn.
Related Issues (20)
- Consider inserting invisible groups, rather than parens, when applying grouping for precedence HOT 1
- Implement `Debug` for the AST nodes HOT 1
- parse_nested_meta don't work on attribute with multiple meta HOT 2
- Struct Literals in ExprLet HOT 1
- Parse `safe` items in extern blocks
- Parse precise capturing syntax HOT 1
- Scope when parsing delimited group content does not necessarily belong to the right Group token
- Parsing function using `parse` referencing enum fails HOT 1
- Parse attributes on where-predicates
- Deny keyword lifetimes pre-expansion
- Parse unsafe attributes
- Parse unnamed C varargs within function pointer types HOT 1
- [Feature Request] Add support for incomplete expression and statement HOT 1
- FieldMutability is missing Parse and ToTokens HOT 1
- Breaking change to `Generics::lifetimes` in v2.0.73 HOT 8
- ExprPath to_tokens() output can't be parsed as an expression due to missing turbofish
- A
- Documentation discrepancy between `parse` and `parse2`
- Generics::split_for_impl can cause clippy::multiple_bound_locations HOT 2
- Error parsing `Option<()>` and `Result<(), ()>` literals in `syn::parse_macro_input`: `unexpected end of input, expected an expression` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from syn.