Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support throwing closures #64

Open
Nemo157 opened this issue Aug 26, 2020 · 2 comments
Open

Support throwing closures #64

Nemo157 opened this issue Aug 26, 2020 · 2 comments

Comments

@Nemo157
Copy link

Nemo157 commented Aug 26, 2020

#![feature(stmt_expr_attributes, proc_macro_hygiene)]

type Error = usize;

fn main() {
    let x = #[fehler::throws] || 5;
    
    dbg!(x());
}

I expected this to work and print Ok(5), with an expansion something like

    let x = || Result<_, Error> { Ok({ 5 }) };
@withoutboats
Copy link
Owner

Yep, I just haven't yet bothered implementing it because stmt_expr_attributes etc are unstable features.

@ijackson
Copy link

ijackson commented Feb 1, 2021

I love fehler and I really really want it for my IEFEs and closures.

Is the expr -> stmt workaround not applicable for #[throws]?

Here's some code from my current project.


    let op = op.try_map(
      |()|{
        let mut ns = pc.prep_piecestate(p.as_ref(), pri)?;
        massage_prep_piecestate(pri, &mut ns);
        <Result<_,InternalError>>::Ok(ns)
      },

Experimentally, I tried this:

    let op = op.try_map(#[allow(some_random_thing)] {
      |()|{
        let mut ns = pc.prep_piecestate(p.as_ref(), pri)?;
        massage_prep_piecestate(pri, &mut ns);
        <Result<_,InternalError>>::Ok(ns)
      }},

and I got the expected warning about an unknown lint.

Then I could write

    let op = op.try_map(#[throws(InternalError)] {
      |()|{
        let mut ns = pc.prep_piecestate(p.as_ref(), pri)?;
        massage_prep_piecestate(pri, &mut ns);
        ns
      }},

The extra { } would be 1000% worth it.

Would it be too confusing if the default error type for #[throws] on a closure would be the error type for the containing function, rather than Error in the enclosing scope? That would save writing type Error = InternalError or whatever at the top of each relevant function...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants