Allow any quoted string to be multiline?
naveen.chwl at gmail.com
Mon Dec 18 11:16:14 UTC 2017
"Protection from bad coding" is about the strongest argument for a language
feature as there could be. Even features that allow doing "more for less"
have the ultimate advantage of reducing the chances of coding mistakes. I'd
say it's the basis of every modern programming language and framework
development out there. I'd be interested to know of any counter-examples if
(small example: arrow functions referencing the outer `this`: avoids
mistakes caused by possible different nested `this`es. I can go through
every feature to show how it reducing the chances of programming mistakes,
but it would take too long)
On Mon, 18 Dec 2017 at 15:17 J Decker <d3ck0r at gmail.com> wrote:
> On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache <claude.pache at gmail.com>
>> > 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
>> > 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss