Add a try_with method to LocalKey

[PlasmaPower]

Rendered

You probably know LocalKey as being the creation of the thread_local! macro.

This is my first RFC, so let me know if I'm doing anything wrong.

[PlasmaPower]

Is it normal for an RFC to go this long without comments? Is there something I can do to help the process?

[pengowen123]

I think having a try_with method would be useful to some, but I'm not sure how often the existing with method causes problems. It is true that the current situation requires checking twice, but if state is removed, using try_with(|| {}).is_ok() isn't pretty either. Because of this, I think state should stay, but as I said, these situations may not be uncommon, so hopefully someone that uses this feature has better feedback.

[PlasmaPower]

Another thing I didn't previously consider about the state is that it's thread local, so if you check state a with call is guaranteed to succeed. I'll change the RFC to not deprecate state. There's also not much reason to deprecate state, so I'll stay on the side of ensuring usability.

[PlasmaPower]

It's been another two weeks since a comment - bump again. Should I continue bumping this, or is there just no interest in this? I'd do the implementation.

[glaebhoerl]

The process description has this bullet point:

• Each pull request will be labeled with the most relevant sub-team, which will lead to its being triaged by that team in a future meeting and assigned to a member of the subteam.

The first part of this has happened but the second has not (and it should, for every RFC). I'm not sure if they're just busy and haven't gotten to it, or if they accidentally overlooked the RFC. In any case I hope they don't mind if I ping them about it: @brson @alexcrichton @sfackler @BurntSushi @Kimundi @dtolnay @aturon [as far as I'm aware I can't ping @rust-lang/libs directly because I'm not on a team myself]

[alexcrichton]

Thanks for the RFC @PlasmaPower but I'm not sure that this will satisfy all current use cases for the state method. Right now different locations will act differently depending on the state returned from that function, whereas I believe the proposed semantics here would fold the Valid and Uninitialized states together. It seems reasonable to me to add a function to more gracefully handle the Destroyed state but I don't think we'll be able to deprecate state yet.

[PlasmaPower]

@alexcrichton The RFC as it stands doesn't deprecate state. While I still haven't found a use case for state, I see why there might be one, so the RFC currently keeps it as is.

[alexcrichton]

If that's the case then this probably doesn't need an RFC and can likely just be a PR. If you'd like you can close this an submit a PR to rust-lang/rust.

[PlasmaPower]

I was wondering about that! The readme did say additions to std needed an rfc, but I guess this is pretty small. I'll just wrap it into the existing state feature I guess.