From 98e9790d4875ad665af6938863718408643cb16b Mon Sep 17 00:00:00 2001 From: Alexander McCord Date: Tue, 4 May 2021 16:28:10 -0700 Subject: [PATCH] RFC: Direct chaining of string terms --- rfcs/syntax-direct-chain-of-string-term.md | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 rfcs/syntax-direct-chain-of-string-term.md diff --git a/rfcs/syntax-direct-chain-of-string-term.md b/rfcs/syntax-direct-chain-of-string-term.md new file mode 100644 index 00000000..fce5fd31 --- /dev/null +++ b/rfcs/syntax-direct-chain-of-string-term.md @@ -0,0 +1,38 @@ +# String terms are directly chainable + +> Note: this RFC was adapted from an internal proposal that predates RFC process + +## Summary + +Allow string literals to be indexed on without parentheses or from an identifier. That is, the following snippet will become legal under this proposal: + +```lua +print("Hello, %s!":format("world")) +print("0123456789ABCDEF":sub(i, i)) +``` + +## Motivation + +Experienced Lua developers occasionally run into this paper-cut even after years of working with the language. Programmers in Lua frequently wants to format a user-facing message using a constant string, but the parser will not accept it as legible syntax. + +## Design + +Formally, the proposal is to move the `String` parser from `exp` to `prefixexp`: + +```diff + var ::= Name | prefixexp `[´ exp `]´ | prefixexp `.´ Name +- exp ::= nil | false | true | Number | String | `...´ | function | ++ exp ::= nil | false | true | Number | `...´ | function + | prefixexp | tableconstructor | exp binop exp | unop exp +- prefixexp ::= var | functioncall | `(´ exp `)´ ++ prefixexp ::= String | var | functioncall | `(´ exp `)´ + functioncall ::= prefixexp args | prefixexp `:´ Name args +``` + +## Drawbacks + +Statements starting by parsing `prefixexp` will now allow string tokens to be parsed despite that the return values of the function calls are now discarded. The recommendation is that we should keep statements starting with string tokens as illegal syntax as it is too niche to support use cases with side-effecting functions. + +## Alternatives + +The infallible parser could be mended in this exact scenario to report a more friendly error message. We decided not to do this because there is more value to gain by simply supporting the main proposal.