Tracking Issue for try_trait_v2, A new design for the ? desugaring (RFC#3058)
#84277
Comments
scottmcm
added
T-lang
Implement the new desugaring from `try_trait_v2` ~~Currently blocked on rust-lang#84782, which has a PR in rust-lang#84811 Rebased atop that fix. `try_trait_v2` tracking issue: rust-lang#84277 Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
Implement the new desugaring from `try_trait_v2` ~~Currently blocked on rust-lang/rust#84782, which has a PR in rust-lang/rust#84811 Rebased atop that fix. `try_trait_v2` tracking issue: rust-lang/rust#84277 Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
|
We have a problem in our project related to the new question mark desugaring. We use the After updating to the latest nightly toolchain this stack trace collection started to work differently. I've created a small project for the demo: https://github.com/artemii235/questionmark_track_caller_try_trait_v2
Is there a way to make the track caller work the same way as it was before? Maybe we can use some workaround in our code? Thanks in advance for any help! |
|
That's interesting -- maybe |
|
From the description:
@artemii235 Do you mind opening a separate issue? |
No objections at all 🙂 I've just created it #87401. |
|
May i suggest changing |
|
How do I use |
|
Use |
|
Why the implementation of
Clarification is welcome as an error type implementing only |
|
see #31436 (comment) |
|
Hi, I'm keen to see this stabilized. Is there any work that can be contributed to push this forward? It would be my first Rust contribution, but I have a little experience working on compiler code (little bit of LLVM and KLEE in college). |
|
@BGR360 Unfortunately the main blockers here are unknowns, not concrete-work-needing-to-be-done, so it's difficult to push forward. It's hard to ever confirm for sure that people don't need the trait split into parts, for example. Have you perhaps been trying it out on nightly? It's be great to get experience reports -- good or bad -- about how things went. (For example, #42327 (comment) was a big help in moving to this design from the previous one.) If it was good, how did you use it? If it was bad, what went wrong? In either case, was there anything it kept you from doing which you would have liked to, even if you didn't need it? |
Experience Report@scottmcm I have tried Overall my experience with this feature is positive. It may end up being critical for my professional work in Rust. My use case is very similar to @artemii235: #84277 (comment). At my work, we need a way to capture the sequence of code locations that an error propagates through after it is created. We aren't able to simply use We would love to be able to do this in our Rust code using just the To get this to work, I made express use of the fact that you can implement multiple different I'd be happy to give more specifics on how I achieved my use case either here or on Zulip, just let me know :) Pros:
Cons:
|
Experience reportI was using Pros:
Cons:
Overall this v2 is a clear downgrade for this particular use case however the end result isn't too bad. If this is making other use cases possible it is likely worth it with better names and docs. The full change: https://gitlab.com/kevincox/ecl/-/commit/a1f348633afd2c8dd269f95820f95f008b461c9e |
This is actually a little bit unfortunate, in retrospect. It would be much better if I could just make use of
To illustrate, here's how things work in my experiment: pub struct ErrorStack<E> {
stack: ..,
inner: E,
}
impl<E> ErrorStack<E> {
/// Construst new ErrorStack with the caller location on top.
#[track_caller]
fn new(e: E) -> Self { ... }
/// Push location of caller to self.stack
#[track_caller]
fn push_caller(&mut self) { ... }
/// Return a new ErrorStack with the wrapped error converted to F
fn convert_inner<F: From<E>>(f: F) -> ErrorStack<F> { ... }
}
pub enum MyResult<T, E> {
Ok(T),
Err(ErrorStack<E>),
}
pub use MyResult::Ok;
pub use MyResult::Err;
impl<T, E> Try for MyResult<T, E> {
type Output = T;
type Residual = MyResult<Infallible, E>;
/* equivalent to std::result::Result's Try impl */
}
/// Pushes an entry to the stack when one [`MyResult`] is coerced to another using the `?` operator.
impl<T, E, F: From<E>> FromResidual<MyResult<Infallible, E>> for MyResult<T, F> {
#[inline]
#[track_caller]
fn from_residual(residual: MyResult<Infallible, E>) -> Self {
match residual {
// seems like this match arm shouldn't be needed, but idk the compiler complained
Ok(_) => unreachable!(),
Err(mut e) => {
e.push_caller();
Err(e.convert_inner())
}
}
}
}
/// Starts a new stack when a [`std::result::Result`] is coerced to a [`Result`] using `?`.
impl<T, E> FromResidual<std::result::Result<Infallible, E>> for Result<T, E> {
#[inline]
#[track_caller]
fn from_residual(residual: std::result::Result<Infallible, E>) -> Self {
match residual {
// seems like this match arm shouldn't be needed, but idk the compiler complained
std::result::Result::Ok(_) => unreachable!(),
std::result::Result::Err(e) => Err(StackError::new(e)),
}
}
}If impl<E, F: From<E>> From<ErrorStack<E>> for ErrorStack<F> {
#[track_caller]
fn from(mut e: ErrorStack<E>) -> Self {
e.push_caller();
e.convert_inner()
}
}However, this does not work because it conflicts with the blanket I could limit my fn foo() -> MyResult<(), io::Error> {
fs::File::open("foo.txt")?;
}
fn bar() -> MyResult<(), io::Error> {
// I need bar to show up in error traces, so I wrap with Ok(..?).
// Without my custom MyResult, I am unable to intercept this invocation of the `?` operator, because
// the return type is the same as that of `foo`.
Ok(foo()?)
} |
|
If I may summarize some of the discussion here, in part for my edification, it sounds like there are several distinct issues being discussed concurrently: 1. Use of the word "residual" in the API The naming of "residual" for "the thing that gets passed up to the caller with the 2. The impact of having both the Several examples have been given in the thread of new APIs involving these traits which see their signatures become increasingly complex as they incorporate these experimental traits. In particular, additional work is needed to tie the 3. A question of the value of splitting Obviously, this was central to the changes from version 1 of the 4. A question over whether the current design can be changed, given its use throughout the standard library. This API has already impacted the standard library, particularly through various 5. Concerns about the As I take it, the use of 6. Concerns about also teaching the helper The method 7. Concerns about how well this design plays with Rust's type inference. Bad-type-inference errors are generally very frustrating to deal with, because (especially without good error messages) you can easily end up in a space where you feel like you're adding random hints to the compiler until it tells you the types are correct. I take it this current API has inference issues, although I don't understand the technical specifics yet. If I've missed any big topics under discussion which are currently blocking progress on v2 of the I do notice that a lot of these are education questions, about how easy it will be for people to understand this new API. This touches on documentation, error messages, and the terminology itself. There are distinct questions about implementation, which basically amount to questions of complexity of bounds and difficulty of correct type inference. All of that said, I'd like to throw my hat in as someone interested in helping. I have a crate called I'm particularly interested in helping around the documentation / education parts of things. Let me know if there's a good place to start. |
Seeing this randomly gave me an idea: How about ‘Alternate’? It seems to fit the ‘neutral’ requirement, not making a particular value judgement beyond ‘different’, and seems to work well in prose, i.e. ‘the alternate path is taken’ I'd say it's also more intuitive for both native and non-native speakers, compared to a slightly odd interpretation of a relatively obscure word |
|
(NOT A CONTRIBUTION) A small change that I think would make this a lot easier to intuit would be to remove the default value for the generic parameter on
Frankly, when I read that you had modified the I also think that "residual" is an unclear name and this isn't an area where Rust needs any more unique terms of art, but as a rule I now try to keep my comments on the lowest rung of Wadler's ladder possible so I won't push that further. As another note, I think the desire the "generalize" APIs that currently involve closures returning |
|
Okay, it does seem like the question of whether the flexibility afforded by To help inform that discussion, I'd like to work on answering some questions:
Each of these can at least attempt to be answered by surveying available Rust codebases, something which I believe has already been done at least in part by others. I'd like to go through the discussions to identify any samples already taken, and likely add more samples myself, to help everyone involved have more concrete reference points for the benefits, additional complexity, and possible demand for this feature. |
Asking this question for unstable functionality rarely gives useful answers, because for most use cases, using a stable-compatible workaround is preferable to using unstable functionality. There are five types which can be stably used with All
The primary purpose of The biggest incidental complexity of the residual system imho is the fact that there isn't a one-to-one mapping between In implementing Something along the lines of (Although the latter is somewhat controversial in retrospect and
Frankly, Basically, being generic over The trait which would actually be appropriate for generic return types is And Expressing maximally flexible monads in Rust is known to be a hard problem. And nearly all of that flexibility is actually used for individually reasonable applications. I think I agree with boats here in that being generic in this way probably isn't necessary, and that As an actual example, see // today's plumbing
type RebindTryOutput<T, O> = <<T as Try>::Residual as Residual<O>>::TryType;
fn Iterator::try_reduce<F, R>(&mut self, f: F) -> RebindTryOutput<R, Option<R::Output>>
where
F: FnMut(Self::Item, Self::Item) -> R,
R: Try<Output = Self::Item>,
R::Residual: Residual<Option<R::Output>>,
;
// "ideal" spelling of today's plumbing
fn Iterator::try_reduce<F, R>(&mut self, f: F) -> R::RebindTryOutput<Option<Self::Item>>
where
F: FnMut(Self::Item, Self::Item) -> R,
R: Try<Output = Self::Item>,
R::Residual: Residual<Option<Self::Item>>,
;
// just Result
fn Iterator::try_reduce<F, E>(&mut self, f: F) -> Result<Option<Self::Item>, E>
where
F: FnMut(Self::Item, Self::Item) -> Result<Self::Item, E>,
;Some kind of similar functionality to Footnotes
|
I'm working on a project since 1 years that fully use all features of Try trait v2 so I hope the FromResiduel feature will not go away... I try to work on the doc to release it one day. I guess it will be a good example for this thread. |
|
Using
At least in the scope of these functions. In some cases, such as |
|
Maybe we can use "exception" rather than error. As the try "triggering" would generally be the exceptional case and the common case would be continuing the straight-line code. |
|
(NOT A CONTRIBUTION)
I think this is the part that people really are concerned about. Frankly, I think I'm going to be very honest about what I think, because I think it is also the opinion of many other prominent community members who are not involved in the libs/lang team clique and have been critical on issues like this or on Twitter. It seems to me that the product design group is trapped in some sort of code golf death spiral where one side creates extremely generic convenience APIs (i.e. The |
yeah, I'd rather have proper functor, monad interfaces in Rust than such hackery (and I'd really appreciate that solely because dealing with ASTs which are extended/modified through various stages of progressing lead to that sort-of naturally, and being unable to abstract over multiple of them makes it harder than necessary to write generic AST mangling libraries imo). |
|
Out of curiosity, @withoutboats, modulo exact naming, Would you consider the use of monadic reprojection be more palatable if it were spelled What if it was a typical generic associated type of the I ask because I'm legitimately interested in whether it's the use of a generic monadic rebind at all (given that it's not strictly necessary when alternative I ask this now prompted by learning of an open draft experiment utilizing a similar double projection scheme to permit allocator-generic collections to do I do agree that doubled type projection is essentially unprecedented in stable std function signatures. The use of a type alias for clarity in the definition of functions doing so is telling, and at an absolute minimum imo the alias should be made public so it will show up in the API docs. I doubted it for a moment, but the use of a Footnotes
|
|
(NOT A CONTRIBUTION)
Both the action of rebinding the wrapped type and the use of double projection to do so add cognitive overhead to the API. A GAT certainly seems simpler than a double projection, though when you start talking about "associated trait aliases" I get very suspicious. I think either aspect of this alone is complex enough to warrant a lot of caution, and require very compelling motivation. I don't see any of the enabled APIs as particularly well motivated, for exactly the reason we've discussed - you can just map things to
My immediate impression is also to be dubious of these fallible allocator APIs. I think allocators is another area where the working group seems to have gone down a rabbit hole and lost touch with how much complexity they're adding to the APIs. I realize there are motivations, but these motivations need to be balanced against how difficult they make std to understand. Maybe I underestimate how compelling the motivations are for that case, I haven't followed the work closely. Overall, I think most people who work on Rust open source are very disconnected from how most non-hobbyist users experience Rust. They don't have time to nerd out about the language, so the model of the type system in their head is a bit wrong or incomplete, and they can easily be frustrated or confused or led astray by the kinds of type wizardry the online Rust community embraces without question. Rust has always been trying to bring a great type system "to the masses" (in total opposition to Rob Pike's statement that users "are not capable of understanding a brilliant language"), but this means recognizing when the cognitive overhead complex types are adding is not justified by the utility they bring to the API. This is especially true when that utility is basically just omitting a type conversion, as in a lot of these Try cases. Of course, this sort of thing is fine in third party crates, where it can be proved out and experimented with and in libraries targeted at a certain kind of user can be effective for that user in achieving their goals. But the standard library should be a bulwark against this sort of programming, because the standard library is the lowest common denominator for all users.
This seems like sloppiness to me, |
|
I don't have too much to say regarding the actual design of the trait, although I think it's apt to bring up this argument I made in the original RFC: rust-lang/rfcs#3058 (comment)
Essentially, however weird the idea of a "residual" is, the term is unique enough that its current meaning in Rust can be learned in isolation. Folks have demonstrated that they have made use of the I think that I feel like maybe more effort should be put into ensuring that the |
|
@CAD97 just to note: I consider such double projection, especially as in applications of them also trait bounds on them can appear in downstream or implementation code, to be an implementation detail that imo shouldn't be necessary, i.e. should be abstracted by the language, leading to a cleaner interface. re: the concern of "niche" or
I believe that it shouldn't be necessary for most normal users to deal with the intricate parts of the API directly at all in most use cases, and if they do, it should be minimally invasive. A long type signature with a large amount of trait bounds and such that can't be abstracted away (except via macros, which makes the docs unhelpful) is a strong anti-pattern, and imo thus warrants a more fundamental solution, e.g. making all monads easier to express in rust instead of abstracting over it via a combination of multiple interlocked traits with potentially confusing semantics, and also potentially harder to read error messages in case of failures of type inference and such. Such interfaces are not only annoying to write/copy-paste and debug, they pose a mental burden, make it harder to present users with good error messages (because the compiler doesn't see the actual abstraction but a workaround around the lack of abstraction, mostly), and might also make type inference/checking unnecessarily harder (and e.g. "simple guesses" by the compiler in case of errors also get much harder, both from the "implement this in the compiler" and "make it fast and maintainable" (also in regard to similar patterns which might evolve in third-party crates, etc.). e.g. (rust-like pseudo-code)enum ControlFlow<B, C> {
/// Exit the operation without running subsequent phases.
Break(B),
/// Move on to the next phase of the operation as normal.
Continue(C),
}
monad_morph<B, C> ControlFlow<B, C> {
type Monadic<C> = ControlFlow<B, C>;
fn pure<C>(t: C) -> Self::Monadic<C> {
ControlFlow::Continue(t)
}
fn flat_map<C1, C2, F>(input: Self::Monadic<C1>, f: F) -> Self::Monadic<C2>
where F: /* function trait used might vary per monad_morph */ FnOnce(C1) -> Self::Monadic<C2>,
{
match input {
ControlFlow::Break(b) => ControlFlow::Break(b),
ControlFlow::Continue(c) => f(c),
}
}
/* a question that remains here would be how to handle the "short-circuiting" generally and effectively (that is, without many nested closures)
* probably similar to the residual stuff, but it would be interesting to see how it could be done generally
* (e.g. simple ControlFlow), while also allowing lazier interfaces (like monads similar to iterators (considering `flat_map` there)) */
}also, another idea would be to introduce some kind of "tagged |
That is already kinda the case. If you're using a Then again, if you're using one of the ready-made functions, you won't need to care much about the traits beyond the documentation. However, unless I'm reading the thread wrong, most of the discussion right now seems to be about the For what it's worth, I think things like trait TryWith<O>: Try {
type TryWith: Try<Output = O, Residual = Self::Residual>;
}I'd be cautious of GATs here, since they'd forbid any impl blocks from adding additional bounds on the projected Output, though I haven't thought about it much so I'll leave it at that. But again, wrong tracking issue. Also I'll echo @withoutboats on removing the default for |
|
As somebody who would like to see this stabilized, what can I do to help? Is there anything I can do to help push this forward? |
|
What still needs to be done? |
|
From what I understand the main blocking points are:
|
|
Alright, response:
Thank you for the answer; I look forward to pushing this through 😄 |
|
@scottmcm Would you be willing to update your checklist to reflect newer changes? |
|
I'd like to raise a concern about the default type parameter on struct Test;
impl<T> FromResidual<Test> for Option<T> {}With some help from someone on discord (@zachs18), we've been able to determine that this seems to be a consequence of there being an Should we perhaps remove the default type parameter, if using it can lead to this problem? Even if it's just as a temporary measure while we fix whatever bug causes the issue: we can always add the default again later. In the meantime, would a PR changing the impl to not use the default parameter be accepted? Here's a MRE, adapted from Zachs' multi-file MRE they shared on the Rust community discord: paste this in a library crate named pub trait MyTry {
type Residual;
}
pub trait MyFromResidual<T> {}
pub struct MyOption<T>(T);
pub enum MyInfallible {}
impl<T> MyTry for MyOption<T> {
type Residual = Option<MyInfallible>;
}
// Of course these two impls won't both compile. Comment one out.
impl<T> MyFromResidual<MyOption<MyInfallible>> for MyOption<T> {}
impl<T> MyFromResidual<<Self as MyTry>::Residual> for MyOption<T> {}
/// using a doctest as a quick way to have an inline external crate
/// ```
/// use example::{MyFromResidual, MyOption};
/// struct Test;
/// impl<T> MyFromResidual<Test> for MyOption<T> {}
/// ```
pub struct Dummy; |
|
For me personally, the main use I would like to see out of a stable Try v2 trait is the ability to write generic adapter types to modify what gets returned on a Such an API could look like this: fn example(arg: Option<u8>) -> Option<u8> {
arg.try_some()?; // returns if arg is a `Some`
Some(42)
}I tried to write up a complete example of this right now, but I'm running into the same issue as the previous poster about the FromResidual impl for Options. Still, here is my attempt: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b1bf5652864308956812f72e71488430 For Results it works fine though, although I had to do a weird workaround to get a Infallible pattern match working, but that seems unrelated to the Try API: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b826e7fd8c8f91e5186501f606f1bcb9 (Pattern match error for who is curios: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=56916aba1cee38c4b1376414cf5e379a) So, in summary:
As for the Lets split up this feature so that we can focus on stabilizing the Also, just an observation, but: When writing the code above, I started to wonder if using the This seems to be a important educational point to me, as explaining how the Output+Residue split works gets harder if you also need to wrap your head around the |
|
Here my project that use try trait, https://crates.io/crates/binator:
I didn't work since few months of this projet, I know I tell previously in this thread I will post it when I release it then it is haha not perfect but that something. That a pretty big project that use try trait in a very practical way. try trait allow me to do really cool stuff having a type that better represent the result of a parser is very nice. and the user can use it like result or option with ?. |
|
Experience report I used try_traits_v2 to implement FromResidual for Result<Infallible, impl Into> and Option for a custom Iterator<Item=Result<Value,EvalError>>. I use this in an AST walker where each node can return zero or more Values, or an error. Before I implemented FromResidual I had to use Result<iterator, EvalError> as return type in the visitor methods in order to use "?", which caused a lot of Ok-wrapping and having to handle the fact that an error could be both the outer result or inside the iterator. Also, returning an empty iterator was very explicit. After FromResidual was implemented I could change the return type on the visitors "iterator" and still use Err(EvalError)? to return errors inside an iterator, or return an empty iterator with None?. All the Ok-wrapping went away. It was quite straightforward to figure out what was needed. The only stumbling blocks was that the default for R in FromResidual made the RustRover autocomplete the impl skeleton incorrectly for my usage, which caused a few minutes of head-scratching. The other thing that took a few tries was to see that the Ok type on the Result impl must be Infallible, but in that case the type errors from rustc were quite helpful. All in all, great feature. Works for me. I don't mind the "Residual" name, even though it's not intuitive for me. Just another concept to learn. The default for R might cause more problems than it solves, though. |
and others
This is a tracking issue for the RFC "
try_trait_v2: A new design for the?desugaring" (rust-lang/rfcs#3058).The feature gate for the issue is
#![feature(try_trait_v2)].This obviates rust-lang/rfcs#1859, tracked in #42327.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Delete the old way after a bootstrap updateRemove theTryV2alias #88223?desugaring #85133FromResidualbut notTryFromResidualbetter (Issue rustdoc removes Try from <Self as Try>::Residual in std::ops::FromResidual #85454)Infallibleare either fine that way or have been replaced by!Iterator::try_foldtry_foldfor iterators for internal iteration #62606)foldbe implemented in terms oftry_fold, so that both don't need to be overridden.)Unresolved Questions
From RFC:
Tryuse in the associated types/traits? Output+residual, continue+break, or something else entirely?From experience in nightly:
FromResidualfrom a type that's never actually produced as a residual (Fix the types in one of theFromResidualimplementations rwf2/Rocket#1645). But that would add more friction for cases not using theFoo<!>pattern, so may not be worth it.array::{try_from_fn, try_map}andIterator::try_findgeneric overTry#91286, that might look like changing the associatedtype Residual;totype Residual: Residual<Self::Output>;.Implementation history
try_trait_v2library basics #84092try_traitfromstdarch, Remove#![feature(try_trait)]from a test stdarch#1142try_trait_v2#84767The text was updated successfully, but these errors were encountered: