TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Follow up to “Changing the rules of Rust”

78 pointsby killcoderover 1 year ago

3 comments

killcoderover 1 year ago
The discussion of the previous post is here:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37545040">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37545040</a>
davidhydeover 1 year ago
&gt; The first crate, foo, is in the 2024 edition, and defines a trait with a single generic method. The second crate, bar, is in the 2021 edition, depends on foo, and implements that trait for its own type.<p>I wasn’t aware that an early edition of rust can reference crates for a later edition. It doesn’t seem that terrible to prohibit this (Probably some very good reason to counter this though!). Editions give us the privilege of not having to constantly update crates that don’t really need to be changed whenever a new rust version comes out. If I do end up making changes to my crate and updating my dependencies then I don’t see it as such a pain to update the Rust Edition of my crate if said dependencies also happen to use a later edition.<p>I do, however, see one downside to this though and experienced it first hand in c# .net standard where it was way better to use the earliest version possible of .net standard for your library to maximise compatibility with things that use it. No incentive to use a later standard and therefore there was stagnation. May not be applicable because you normally distribute compiled binaries but food for thought.
评论 #37559911 未加载
Georgelementalover 1 year ago
Follow-up from the author on Reddit:<p>&gt; After a few more minutes thought:<p>&gt; When you upgraded `foo` from 2021 to 2024, `cargo fix` would have had to add a `Leak` bound to the parameter on the method. Removing that bound would be a breaking change. Therefore, the issue could actually be in `bar`. But this also highlights another issue: it&#x27;s a breaking change to start allowing `!Leak` types to be passed to any generic method of a trait, even with this firewall. That means like `Iterator::map` can&#x27;t take a closure which has a `!Leak` type in its state, for example.<p>&gt; But also what is the issue in `bar` if so? In 2021 edition, the interface of any trait you impl coming from a 2024 edition crate is tested under 2024 edition somehow? Does that work? What does the error message say to you?<p>&gt; My point is not that this is impossible, but that its not easy at all.<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;16ltgn1&#x2F;comment&#x2F;k145i6z&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;16ltgn1&#x2F;comment&#x2F;k145i...</a>
评论 #37557673 未加载