Enum support for pin_project! macro

[taiki-e]

Like pin-project, by passing an argument with the same name as the method to the attribute, you can name the projection type returned from the method. This allows you to use pattern matching on the projected types.

use pin_project_lite::pin_project;
use std::pin::Pin;

pin_project! {
    // The `#[project]` (and `#[project_ref]`) attribute must precede the other attributes except for `#[doc]`:
    #[project = EnumProj] 
    #[project_ref = EnumProjRef]
    #[derive(Debug)]
    enum Enum<T, U> {
        Struct {
            #[pin]
            pinned: T,
            unpinned: U,
        },
        Unit,
    }
}

impl<T, U> Enum<T, U> {
    fn method(self: Pin<&mut Self>) {
        match self.project() {
            EnumProj::Struct { pinned, unpinned } => {
                let _: Pin<&mut T> = pinned;
                let _: &mut U = unpinned;
            }
            EnumProj::Unit => {}
        }
    }
}

Also, this does not provide support to tuple variants for the same reason that it does not support tuple structs.

[taiki-e]

I'm wondering what syntax is preferable, so I would appreciate any feedback.

[ghost]

What if the attribute syntax was used, similar to the one in pin-project?

So perhaps something like #[project = EnumProj] above the enum definition.

[taiki-e]

Ah, that looks like a good idea. There may be a limitation like #3, but I'll try it.

[taiki-e]

I've tried the attribute syntax and it looks good overall. (Thanks @stjepang for the suggestion!)

Limitations of the current implementation I know of are:

• The #[project] (and #[project_ref]) attribute must precede the other attributes except for #[doc]:

  pin_project! {
      /// documents (`#[doc]`) can be placed before `#[project]`.
      #[derive(Clone)] // <--- Error
      #[project = EnumProj] 
      #[derive(Debug)] // <--- Ok
      enum Enum<T, U> {
          Struct {
              #[pin]
              pinned: T,
              unpinned: U,
          },
          Unit,
      }
  }

  This is probably impossible to fix, but I don't think it's too bad.

• The diagnostics got worse. In most case, the error message is always "no rules expected the token [" 😅
  This seems to be caused by first parsing the option. This is bad, but it may be fixed in some way.

[ghost]

It's okay if there are a few limitations with known workarounds. I think it's amazing that you managed to pull this off at all without procedural macros :)

[taiki-e]

I think the implementation is now basically complete, but I'll look into limitations and minor bugs before the merge.

[taiki-e]

Filed #36 to track diagnostics issues. I'm okay with merge this.

bors r+

[bors]

Build succeeded:

• ci

[taiki-e]

Published in 0.2.0.