3 ms·
Inclusion of parts of rand might be a good idea, but syn seems to need breaking changes as for long as the Rust language is getting new features: > Be aware th
by est31 7y ago
Inclusion of parts of rand might be a good idea, but syn seems to need breaking changes as for long as the Rust language is getting new features:
> Be aware that the underlying Rust language will continue to evolve. Syn is able to accommodate most kinds of Rust grammar changes via the nonexhaustive enums and Verbatim variants in the syntax tree, but we will plan to put out new major versions on a 12 to 24 month cadence to incorporate ongoing language changes as needed.
https://github.com/dtolnay/syn/releases/tag/1.0.0 https://github.com/dtolnay/syn/releases/tag/1.0.0
- raphlinus 7y agoSince stdlib and compiler releases are tightly coordinated, that shouldn't be a problem, no?
- anp 7y agoHow do you accommodate breaking changes to the public interface of std?
- raphlinus 7y agoRight, I see your point here. There are non-trivial issues that need to be worked out, which I'm sure is one reason it's not in the library yet. Another (mentioned elsewhere) is that it takes time to converge on what a good API might look like.
- heavenlyblue 7y agoWell, with non-std I can always downgrade or upgrade the library. With std I am bounded by the current language version.
- snovv_crash 7y agoYou can only down or upgrade if uour dependencies don't depend on it too. Having a defacto standard library has more issues IMO than a real standard library.
- est31 7y agoMy core argument is that libraries usually do need breaking changes, and including them into std turns them into zombies that can never be removed. I think python has issues with this. And the syn example that I pointed out above shows that Rust isn't immune from this either.