Introduce foreign blocks

language design
1

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!({{{
<p>Hello!</p>
}}});
let documentation = ({{{
Example documentation
}}}).trim();

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

2

How is this different from raw string literals?

3

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

4

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")

3 Likes
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.