Pre-RFC: Catching Functions

[withoutboats]

@inejge

On the face of it, that’s not much. However, I’m aware that a search of this kind simply can’t detect things like exploratory integration and refactoring, where the ergonomic burden of switching between fallible and infallible versions exists as well. So, take with a grain of salt.

I would expect crates.io to be a very poor showing for this kind of operation:

• It is far more likely to occur within a commit than between commits, much less between releases (where it is a breaking change if its in the public API).
• It is far more likely to occur in end applications (which tend to have a lot of code "in the middle of the result monad" than libraries do). Libraries dominate crates.io.

Occurring between releases in 7-10% of libraries is, in my view, a very high showing.

@nikomatsakis

But it will also happen that, for some users, they will first encounter errors. For example, I often teach people – as a starting step – to use some framework or something, and enums are just not needed yet. But they still may need to call some_str.parse::<u32>() (for example), in which case they encounter the possibility of error. And maybe then it’s nice to be able to just ‘use errors as errors’, without first diverting to enums.

I would push harder on this. In the long run, as Rust gains production adoption, most users will learn Rust "on the job." Since we've seen that applications tend to have huge amounts of code that lie somewhere between the origins of errors and where they are handled, I would find it very likely that a new users' first commit to the code base they are learning within will be in the context of error handling.

@rpjohnst

I have been assuming the block (and in the full proposal, the function) would always wrap.

That is what the proposal would have; I haven't heard anyone voice support for accepting both T and Result<T, E>.

---

@josh

There’s a feeling in this thread that feels like inevitability, like “of course this is going to happen, we just have to sort out a few details”.

I want to add to Aaron's excellent post that this thread has nullified my productivity since I started it. I wrote this sketch in 30 minutes, its nowhere near the end of the line, and there's absolutely nothing inevitable about it. The reaction like this is both unwarranted and uncollegial.

I expected to receive a smattering of comments, constraints, iterations, etc, that I could review between other tasks during the week. I was faced with this deluge of feedback that had to become my primary focus. I also found it emotionally exhausting, because I have felt that every time I try to drill deeper into the nuance of the question I in turn receive very reactive, dramatic broad-strokes responses that don't seem willing to drill down with me into the finer grain details of the trade offs involved.

What's really unfortunate is that what this thread demonstrates to me that when an idea is at the "30 minute sketch" stage, if I suspect it will be at all controversial, I can't post it on this forum or dealing with that thread will be what I am doing all week. I'm likely to turn to this forum less for early stage feedback like this. Instead I will develop ideas in a more private way and post them only when I can roll out elaborate and convincing narratives to go with them. This does not increase the influence of this community over the direction of my work.