Re: Why non-escaped newlines are prohibited in single-quoted string literals?

[nobody <nobody+lua-list@...>]

On 2017-01-29 13:22, Egor Skriptunoff wrote:
> Hi!
> 
> I have a suggestion to allow using of non-escaped newlines
> in literal strings delimited by single or double quotes.
> 
> I think it would be handy all these three definitions to be
> syntactically valid and equivalent:
> 
> local str1 = 'A
> B'
> local str2 = 'A\
> B'
> local str3 = 'A\nB'
> 
> Currently, the definition of str1 gives syntax error.
> I don't see any problems that could appear by enabling syntax
> used for str1.
> 
> I think Lua would be a bit more comfortable to use
> with unnecessary prohibition removed.
> 
> -- Egor

I don't think it's "unnecessary prohibition".  Zoom out a bit:

Lua is dynamically typed, meaning anything that's not a syntax error
will have to be detected at runtime.  (And then it's just one unchecked
`pcall` away from being silenced.)  A lot of things that "should" be
found at load time are actually valid syntax and can only be detected at
runtime – e,g, `local r, g, b foo()` (which you'll notice because r,g,b
are nil) or `local r, g b = foo()` (which you'll notice because r,g are
nil and you get a global b).

Now, these last two are already majorly annoying, even though it's very
rare that you actually forget a ',' or the '='.  But if it happens, it
may be surprisingly hard to track down the actual place where it's
missing.  (If you're lucky it's one look at the code, if you're unlucky
and suspect other reasons it can easily take you an hour...)

Back to strings:  I'd say the chance of accidentally a '"' or "'" is
much higher than for the above example.  If unprotected newlines are
valid, the string extends over several lines until the start of the next
string (which is now parsed as the end of the previous string).  The
chance of getting a syntax error here is quite high but not 100%.  If
the string contains a single word, the following closing quote (now read
as an opening quote) makes a valid call - an example:

    x="unclosed
    y="foo"
    z="bar"

will read as

    y="unclosed\ny="
    foo( "\nz=" )
    bar( "<syntax error at eof>

and I don't have a good idea on how to produce a syntax error pointing
at the actual problem and not a few dozen (or hundreds of) lines below.
(And this is still ignoring strings that contain valid Lua code… the
error messages would probably become even more confusing.)

One thing that slightly improves the detectability is permitting
newlines but not immediately following the opening '"'/"'".  In the
example, that would error at

    x="unclosed\ny="
    foo( "<syntax error: newline after '"'>

but happily accept

    x="unclosed
    y="foo" -- blah burble
    z="bar"

so it's not that much better.

(And I haven't even looked at how the use of "'" in strings or comments
plays out - that's another big influence on where strings seem to open
or close and so on...)

I don't think the slight increase in convenience is worth the probably
quite large decrease in debuggability / error message quality.

-- nobody