Different forms of "code reuse": polymorphism & macros

Starting from:

I answered with:

To which @steffahn answered:

I would like to continue that discussion, but not derail the original thread, so let's start a new one :slightly_smiling_face:

I've stumbled upon the following blog post which seems like quite a comprehenseive review/comparison of the different approaches:


with the following neat diagram:

Tangentially, it also reminds me of:


I like both blog posts because they include macros in their view of "code reuse" or "general polymorphism". Indeed, while (codegen-)compiler-aware polymorphism, in Rust, is:

  • either achieved trough generics (static dispatch through monomorphizations),
  • or through dyn Traits ([extensible] dynamic dispatch through virtual function "tables" (actually structs, and dubbed vtables));

the truth is that Rust generics are not that different —from a user's perspective— from C++ templates, and yet those are —under the hood— closer to macros than to Rust generics.

So there is kind of a gradient, there, between performing "copy-pastes" / monomorphizations during the machine code generation (generics) or during the source code generation (macros, and kind of like the C++ templates).

  • I personally draw the line as to whether "type errors" are caught early, as with Rust generics —modulo const resolution errors, and their infamous post-monomorphization errors—, or late / post-monomorphization, as with Rust macros or C++ templates.

Hence this thread, to have a general discussion about these things, but with no concrete questions yet; just to have an area to brainstorm about "broader polymorphism", and things other languages / compilers do or enable, and how maybe they could be emulated in Rust (e.g. using macros).

For instance, it would be nice to try and prototype actual dictionary passing in Rust.

1 Like

I haven’t looked a the blog post yet. Yesterday and today, I thought about roughly what an IMO reasonable MVP for polymorphism in Rust could look like. Some forms of “dictionary passing” can be done manually on the basis of that (e.g. passing around some &dyn Fn()s and such). Too much fancy interaction with the trait system seems unnecessary for an MPV. I’ve written down some aspects of it here, feel free to take a look. There’s a code example at the end.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.