make type modifiers usable for macro substitution

[metajack]

Currently you can not pass @ or ~ or @mut to a macro by itself, but this would be useful in a few cases. I tried doing this to add Clone trait implementations without copying the code:

macro_rules! ptr_clone_impl(
    ($p:something) => {
        impl<T:Clone> Clone for $p T {
            #[inline(always)]
            fn clone(&self) -> $p T { $p (**self).clone() }
        }
    }
)

ptr_clone_impl!(~)
ptr_clone_impl!(@)
ptr_clone_impl!(@mut)

But as far as I can tell there is no fragment specifier that will work for those tokens.

[bstrie]

I know that @pcwalton has been interested in making ~ and @ act just like any other type, so perhaps this is worth supporting (assuming that user-defined types would normally be valid in this context).

[pnkfelix]

~ and @ are type-constructors, not types, no? (Still, it might be sense to add support for them to the macro-system. I.e. have some way to pass around these type -> type operators.)

[catamorphism]

Bug triage: doesn't look like a release blocker to me.

[emberian]

cc @jbclements

I feel like this is tricky, although it shouldn't be too hard for just the sigils.

[emberian]

Now that we have box and have removed those other types, this doesn't make quite as much sense. Once box itself infers the boxed-type this shouldn't be necessary. What's missing is to be able to have something like type level functions... I have Box, I want to apply it to T to get Box<T>, but our syntax doesn't really make that convenient.

Just some scattered thoughts..

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#285