Allow any quoted string to be multiline?

Michael Rosefield rosyatrandom at gmail.com
Mon Dec 18 11:19:51 UTC 2017


There can absolutely be breaking changes from doing that. Take this, for
example:

const someObj = { 'some.key': 'some value' };

That throws an error if using template literals, as you need to use
computed property syntax (i.e., enclose the template literal in square
brackets).

[image: image.png]

On Mon, 18 Dec 2017 at 10:09 Alexander Jones <alex at weej.com> wrote:

> 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.
>
> On 18 December 2017 at 09:47, J Decker <d3ck0r at gmail.com> wrote:
>
>>
>>
>> On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <claude.pache at gmail.com>
>> wrote:
>>
>>>
>>>
>>> > Le 17 déc. 2017 à 22:03, J Decker <d3ck0r at gmail.com> a écrit :
>>> >
>>> > I do see there are work-arounds (similar as using a hammer to put in a
>>> screw)
>>> >
>>> > 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.
>>>
>>> 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...
>>>
>>> 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.
>>>
>>>
>> It's not actually :) lightest I can imagine is to allow single and double
>> quoted strings to be multiline also.
>> 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.
>>
>> 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.
>>
>>
>>
>>
>>> —Claude
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171218/9f112b00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12726 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171218/9f112b00/attachment-0001.png>


More information about the es-discuss mailing list