TypeFns, variadic generics, compile-time reflection, macro-like fns

[CAD97]

(minor note:

Macros 2.0 is a planned thing. Macro invocations will also always have the ! to indicate that they expand to more code than just a simple function call.

Whether and how macros are able to interact with the type system is an unresolved question.

#![feature(decl_macro)]

macro my_macro($thing:ident) {
    // expands to
}

)

[eaglgenes101]

You’re implementing your events as callbacks, which can be straightforwardly subsumed into futures.

[Soni]

so do that, in your code.

I prefer events, especially if they have some sort of inheritance - which mine do, even if using it isn’t the nicest thing in the world.

[matt1985]

It’s fine to like this event system.

However,convincing people to change the language to suit your usecase requires that you have a good/convincing argument why this is an important feature that should be in the language,and non-contrived examples of using this feature that could be implemented if it were accepted.

I would recommend that you look for other cases where people asked for reflection in Rust,and start compiling them so that you can have a good argument for it.

BTW:As I said before I am not opposed to adding reflection to the language,I just don’t need it.

[Soni]

“Macro fns” expand to little more than just an #[inline(always)] function call - it’s a function call that can define statics. That’s it. That’s the whole selling point. It’s for performance.