<div dir="ltr">I question why 3 forms of quotation exist in modern codebases. Just use template literals. The only reason not to is resistance to change. ESLint will autofix for you.</div><div class="gmail_extra"><br><div class="gmail_quote">On 18 December 2017 at 09:47, J Decker <span dir="ltr"><<a href="mailto:d3ck0r@gmail.com" target="_blank">d3ck0r@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
> Le 17 déc. 2017 à 22:03, J Decker <<a href="mailto:d3ck0r@gmail.com" target="_blank">d3ck0r@gmail.com</a>> a écrit :<br>
><br>
> I do see there are work-arounds (similar as using a hammer to put in a screw)<br>
><br>
> I don't see a reason for why not allow multiline strings for other quote types.  I know... because people want more errors and to have their hand held to identify missing close quotes?  much like the desire to add types and type checking.<br>
<br>
</span>Yes, you gave a valid reason just after having said you didn’t see a reason: transforming bugs (missing quote) into early errors, so that it is easier to debug...<br>
<br>
The obvious workaround, i.e. using a template literal without placeholder, doesn’t seems too heavy-weight; on the contrary, it is probably the lightest one can imagine.<br>
<span class="m_-2539678207435077610HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div></span><div>It's not actually :) lightest I can imagine is to allow single and double quoted strings to be multiline also. </div><div>I was considering this because of an issue on my extended json parser.  during development it simplified the code making a single path for gathering a string that only had to check for closing quote or backslash.  having to test for 4 more characters was then 3x the work... so I just cut out the extra work, since it break anything.  The only thing left was ... that it didn't break anything if a newline was found.</div><div><br></div><div>So I figured I'd mention the possibility here and see how much push back I got.  I don't actually think that 'protection from bad coding' is a very strong argument.  there's lots of single character omissions or insertions that can cause ghosted errors that aren't nearly so obvious.  Especially since syntax highlighting would show a overflowing string very quickly (more than missing a + in += or having a +  on an = that you didn't mean for instance).  It would be a change that would take some time to propagate to a lot of tools; but is a change that's entirely backward compatible and breaks nothing from the past.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_-2539678207435077610HOEnZb"><font color="#888888">
—Claude</font></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>