Proposal: replace statement

[alrz]

replace statement

Summary

Extend replace scope to statements.

Motivation

While replace is a powerful language feature targeting augmentating code generation, there still exists a need for "modifying" code generation that actually operates on the statement level, for instance: #85.

Proposal

I propose an statement form of replace that passes the syntax tree of the contained region to generators.

{
  replace {
    // ...
  }
}

IDE experience

The main challenge for modifying code generation is autocomplete and debugging experience. If an assembly weaver built into the compiler pipeline, there is a chance that it modifies the very code that you are typing. So it is nearly impossible to expose the whole syntax tree to such tool for modification and keep IDE experience as sane. However, if we limit the scope to a specific statement, we can defer code generation in that region until full compilation action is triggered. Debugging would work on the generated (and possibly modified) syntax tree .

Generator resolution

It's possible to pass all replace blocks to all registered generators, if the code comply with the expected pattern of a generator, it can inspect and return the modified syntax tree, otherwise it would return it as-is.

Alternatively, we can use source attributes to select a particular generator,

[[MyGenerator(...)]]
replace { ... }

Alternatives

With source attributes, it's possible to declare a base attribute for all modifying generators, and apply it directly to the code/block that is going to be modified.

class MyGenerator : GeneratorAttribute { .. }

[[MyGenerator]]
{
}

Variations

There could be an expression form of replace that operates directly on expressions, however, since replace is a contextual keyword, the syntax will be ambigious (just like await). An option would be to annotate the containing method with a modifier.

See also

• [Proposal] add supersede modifier to enable more tool generated code scenarios. roslyn#5292
• [Proposal] enable code generating extensions to the compiler roslyn#5561
• https://github.com/dotnet/roslyn/issues/6671

[vladd]

@alrz Ok, but where does the generated code go? With methods, it goes to another method in the same (partial) class, but with statements?

[alrz]

@vladd

Generated code will compile to the resultant assembly, so basically, it doesn't need a place to "go", but for debugging, I think IDE can help, for example, it can replace replace blocks with textual representation of the generated AST during a debugging session.

[gafter]

I don't get it. What are the language semantics of a replace statement.

[alrz]

@gafter

Basically, it's just a container, so to the language it wouldn't be any different than a simple block. But the compiler would pass the contained syntax to a generator for further inspections. That's why I also suggested to use a source attribute to annotate such blocks since replace as a standalone statement is probably redundant.

[gafter]

This proposal implicitly assumes that a single bit of information (this block should/not be replaced) is enough to inform all of the generators which of them should make which kind of change to this code.

[alrz]

AFAIK that's how analyzers work, they all take some sort of syntax node and only if it matches with some other patterns and constraints they would trigger the code generation - at the request of the user.

However, some generators might be able to work on any code. I believe using source attributes would also address that issue since you explicitly specify which generator should be triggered on the block.

PS: I started off with this idea as an statement form of replace but ended up with an unrelated syntax, in effect, it would still replace some statement though.

[vladd]

@alrz Your proposal seems to require quite strange IDE experience: it needs to show the (editable) original statement without possibility of debugging (single step, breakpoints etc.), and the (read-only) expanded statement, which can be debugged step by step and so on, right? This is not going to be very friendly for the code editors.

[alrz]

@vladd I agree, I'm going to retire this proposal in the favor of dotnet/roslyn#18364.