Introduce foreign blocks

Currently, Rust parses any and all code it sees, this is often what we want, but sometimes we don't want that. A foreign block would fix that.

A foreign block, defined as {{{$1}}}, where $1 is anything but }}}, would tell the Rust parser not to parse anything inside of there. It'd simply treat it as a string.

There would be two types of outputs: const str (When used in code), and block (When passed to macros directly)

A block would be a special type of string for macro_rules! macros, like you'd use ($x:expr), you can use ($x:block). A block will be passed in as a string, and for all purposes outside of the compiler, it is just a string.

An example of usage would be:

let homePage = html!({{{
let documentation = ({{{
Example documentation

In current Rust, you'd need to do

let homePage = html!(<p>"Hello!"</p>);
let documentation = "Example documentation";

Due to compiler limitations

This proposal would fix that

Please note I am not a compiler contributor, I'm just someone who got an idea and wanted to share it to see what people who know what they are doing think of it

How is this different from raw string literals?

A template literal and foreign block would both be a string, but serve different purposes

Passing r"<p>Hello</p>" to a macro and {{{<p>Hello</p>}}} would have different meanings

The raw string literal would contextually be a string. A foreign block would contextually be some kind of code, or some kind of very special string

It would only ever be passed through a macro as block since you didn't say a block could be passed as anything else so ultimately after macro expansion that block would still turn into a string. Which means all it does is attaching a sort of type tag to the string literal. Which, yeah, sure, it would be nice if we had types in macros. But we don't because it runs before types are a thing. An ad-hoc addition that lets you have exactly two different types of string (string-as-literal, string-as-block) seems like a quite narrow, special case. Can't this equally be solved by adding some token to the html macro that declares that the next token is not a regular string but a pass-through one? html!(@ "This gets passed through") vs. html!("This doesn't")