Macros a la Rust?

[colejohnson66]

I understand why C-style macros aren't supported by C#. They're nothing more than textual replacements with a whole mess of rules for when to substitute or not. However, has there been any discussion on Rust style macros?

There's source generators, sure, but they're not as elegant as Rust macros, and are more akin to Rust's "proc macros". For example, Rust's vec![] macro is defined roughly as:

#[macro_export]
macro_rules! vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $(
                temp_vec.push($x);
            )*
            temp_vec
        }
    };
}

Sure, that could be faked with something like:

public List<T> ListMacro<T>(params T[] args) => new(args);

But that causes a copy, and if we wanted to do something more complex like define functions, C# can't do it (without source generators) whereas Rust's macros can.

[HaloFour]

The team has seemingly been reluctant to consider macro-like systems for C#. I would suggest that their complexity is probably the biggest stumbling block. These kinds of macros are effectively a separate language within the language which would require their own grammar and rules in the specification. With source generators none of that was necessary as the language itself did not change, and the compiler support required modest effort.

[colejohnson66]

I agree that it wouldn't be easy. I just feel source generators are a bit lacking as you're just manipulating text, not tokens. That leads to things like Fody being used instead. Yes, Fody is older than source generators, but it's still popular.

It's currently easier to just write a Python or JS script that would run the C preprocessor over all my .cs files than using source generators.

[TactiTac0z]

I feel like it could be made rather simple depending on how it's implemented of course.
Unfortunatly using source generator is just no good if doing something would require a source generator to rewrite a user source file (which is something I personally do to a certain extend in some areas, but I'm sure most peolpe here know the pain that come from that - spoiler alert IDE support)
Like for instance in some cases we need to do stuff like

#if TTRoot
namespace TactiToolsCore.InternalRoot;
#else
namespace TactiToolsCore.Event;
#endif

I would love to be able to "define" a macro somewhere like

#macro INTERNABLE_NAMESPACE
#if TTRoot
namespace TactiToolsCore.InternalRoot;
#else
namespace TactiToolsCore.#macro-arg0;
#endif
#endmacro

// then using the macro

#INTERNABLE_NAMESPACE$Event

Or

#macro PTS
[System.ThreadStatic]
public static 
#endmacro

// -
#PTS int ts_number;

Or something along those lines.
I'm not familier with Rust so I'm sure this is no where near how it works in that, this is just the most recent discussions I have found about it.
If it becomes an actual feature IDE's will have support for it, even proper diagnostics using the same system many IDE's use to handle source file linking.
To write a source generator my self to do stuff like this is easy enough, but unless we are all willing to write our own IDE to support it then that doesn't really help.

You think there is anyway something like that could be considered one day @HaloFour ?

[Xyncgas]

One significant advantage of Macro is giving developers a break while still keeping codes verbose.
Isn't it one of the main reason you can use to attract users to use your product?
Because the using MName = System.UInt32; method doesn't work with generics

[Xyncgas]

Here's a poll you can participate on this topic
https://poll-maker.com/QKY13WZ5F

[CyrusNajmabadi]

@Xyncgas benefits have to be weighed against costs and drawbacks.