[nitsky]

I am surprised the blog post doesn't mention the stabilization of binding both by-move and by-ref in patterns [1]. I have personally been waiting on this one for several years. Time to go remove my workarounds. Thanks!

[1]: https://github.com/rust-lang/rust/pull/76119

[steveklabnik]

There is always an art to what to decide to put in vs not, and it wasn't 100% clear to us how important folks consider this feature. We waffled a bit, it was basically a coinflip on putting it in or not.

[the_mitsuhiko]

I generally started going from the blog posts to the changelog as I felt for a few times now that the stuff I care about was not in the announcement blog post.

[steveklabnik]

Yeah, it's just impossible to please everyone, especially in releases like these, which have a few minor things and that's it. Rust 1.51 will be easy, given that "const generics" is a huge headline feature almost every Rust user will care about, but for features that are full of tiny things, it's just way way less clear.

This has the funny effect of posts getting harder to write as time goes on; we have less releases with big, important features, and more releases with "tons of bugfixes and some minor improvements."

[Kinrany]

Do you have any ideas for changing the format, to make it easier to write about these things in a way that lets people read the parts they want?

Possibly write about the reasons something was changed and the use cases improved, instead of the changes themselves?

[steveklabnik]

I don't, because I think it is fundamentally impossible. I'm willing to be proven wrong though!

I do try to write about the reasons why and use-cases improved. One of the issues is that that increases the amount of text, which directly goes against the idea of quickly finding what you want.

At the end of the day, if you want to know everything, you have to read everything. There's no shortcuts. I try to highlight the best things that the most people will want to know about, but if you really want to know everything, there's no better way than going straight to the source, like I do to create the post in the first place.

[kzrdude]

You don't want to sign Lin Clark for doing helping write these? If we could dream :)

I was imagining something spatial, a drawing, a map, something that makes it possible to overview and place the new features in context with each other. Probably nothing that can be realized.

[lumost]

It might be worth separating the different improvement areas by section to let people zoom in on what they care about.

[steveklabnik]

We already do that in a pretty granular way, between language, library, compiler, and toolchain features, unless I'm misunderstanding you.

Regardless, I don't think the cost/benefit is right here; the posts and notes are already pretty short, and should only take a few minutes to read, even if you read all of them.

[lumost]

aye - the note is very short, I meant that given an index at the beginning one could have more detailed sections that highlight the changes for each section of the language to help avoid "can't please everyone" at the risk of "pleasing no one".