1. 7
  1. 3

    In Swift, this would be:

    struct Test {
        let `in`: String
    }
    
    let a = Test(in: "asdf")
    

    I think the example doesn’t really show the point of r#. You could just as well just change the name to _in or __in instead and it would probably be more readable than r#in.

    1. 3

      As always, the RFC gives a lot of motivation. https://rust-lang.github.io/rfcs/2151-raw-identifiers.html

      (E.g. the ability to name a function like a keyword, particularly useful for FFI use)

      1. 2

        But if you always call it using r#, you have essentially renamed the function. It would be acceptable if it was only at declaration or where disambiguation was otherwise needed, but here it seems to surface at every point of use.

        1. 4

          Imagine function:

          extern "C" r#match() {
          
          }
          

          bc. a dynamic library needs to export this symbol. I agree in general, r# is not to be used in interfaces intended for humans.

          1. 6

            Hm, I don’t think that’s what is happening here. For FFI purposes, we have a dedicated attribute, link_name

            https://doc.rust-lang.org/reference/items/external-blocks.html#the-link_name-attribute

            Unlike r#, it’s not restricted to valid rust identifiers (ie, it allows weird symbols in name).

            My understanding that 90% of the motivation for r# was edition system, and desire to re-purpose existing idents as keywords. Hence, unlike Swift or Kotlin, Rust deliberately doesn’t support arbitrary strings as raw identifiers, only stuff which is lexically an ident ((_|XID_Start)XID_Continue*).

      2. 3

        The example uses debug serialisation (#[derive(Debug)]), which perhaps isn’t the best example of why it matters, but at least proves the point.

        The name matters in serialisation, and this could be generated code. I’ve had this exact problem in two unrelated protocol generators that happened to generate C++, and got funny build errors when I tried to define messages with fields like delete and static.

        1. 1

          OK, but that option hasn’t gone anywhere. You can still name it _in if you want. There’s plenty of niche cases where it would be nice to keep the identifier, mostly when interfacing with code you don’t control.

          1. 1

            Yes, exactly, I figured out about raw identifier while checking a PR at sqlparser crate. where author used in for parsing one of the statements.