ASI and wrapping long lines
# Irakli Gozalishvili (15 years ago)
Another pattern of solving this that people writing semicolonless code already employ is:
function a() { return ( "some string" ) }
-- Irakli Gozalishvili Web: www.jeditoolkit.com Phone: +31 614 205275 Address: 29 Rue Saint-Georges, 75009 Paris, France goo.gl/maps/3CHu
Another pattern of solving this that people writing semicolonless code
already employ is:
function a() {
return (
"some string"
)
}
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Phone: +31 614 205275
Address: 29 Rue Saint-Georges, 75009 Paris, France <http://goo.gl/maps/3CHu>
On Tue, Jul 27, 2010 at 00:29, Allen Wirfs-Brock <
Allen.Wirfs-Brock at microsoft.com> wrote:
> I confess that I haven’t waded through the entire Rationalizing ASI
> thread. I generally agree with Brendan concerning the horse and the barn.
>
>
>
> However, there was one ASI problem that was raised for which I think we
> could at least provide a basic remediation:
>
>
>
> >We talked at the July 2008 Oslo ("Harmony") meeting about one way to
> mitigate the unreported dead-code error that results from
>
> >function foo() {
>
> > if (some) {
>
> > if (deep) {
>
> > if (random) {
>
> > if (logic) {
>
> > if (ending) {
>
> > if (in_a_very_long) {
>
> > return
>
> > "I believe in the 80 column limit, so I
> wrapped";
>
> > }
>
> > }
>
> > }
>
> > }
>
> > }
>
> > }
>
> > return "LOL";
>
> >}
>
>
>
> The problem here is that the programmer has a legitimate reason to want to
> break a return across two lines and they can’t. There is an easy fix for
> this. It’s called “line continuation”.
>
>
>
> In ES5 we standardized the de facto browser behavior for line continuation
> within string literals: LineContinuation :: \ LineTerminator Sequence.
>
>
>
> A LineContinuation certainly could also be allowed as an alternative for
> whitespace. Then if [no LineTerminator here] is reinterpreted to not match
> a LineContinuation then the above return could have been written as:
>
>
>
> return \
>
> "I believe in the 80 column limit, so I used
> a LineContinuation";
>
>
>
> It wouldn’t help people who didn’t know about line continuation but it
> would allow those who do know about them the flexibility to format their
> code the way they want it. I would normally say a language shouldn’t need
> cruft like this. However, once you’ve go down the road of making line
> breaks syntactically significant it is arguably reasonable to also allow
> for line breaks that explicitly have no syntactic significance.
>
>
>
> Allen
>
> _______________________________________________
> 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/20100728/e6e8cd27/attachment.html>
I confess that I haven't waded through the entire Rationalizing ASI thread. I generally agree with Brendan concerning the horse and the barn.
However, there was one ASI problem that was raised for which I think we could at least provide a basic remediation:
The problem here is that the programmer has a legitimate reason to want to break a return across two lines and they can't. There is an easy fix for this. It's called "line continuation".
In ES5 we standardized the de facto browser behavior for line continuation within string literals: LineContinuation :: \ LineTerminator Sequence.
A LineContinuation certainly could also be allowed as an alternative for whitespace. Then if [no LineTerminator here] is reinterpreted to not match a LineContinuation then the above return could have been written as:
It wouldn't help people who didn't know about line continuation but it would allow those who do know about them the flexibility to format their code the way they want it. I would normally say a language shouldn't need cruft like this. However, once you've go down the road of making line breaks syntactically significant it is arguably reasonable to also allow for line breaks that explicitly have no syntactic significance.
I confess that I haven't waded through the entire Rationalizing ASI thread. I generally agree with Brendan concerning the horse and the barn. However, there was one ASI problem that was raised for which I think we could at least provide a basic remediation: >We talked at the July 2008 Oslo ("Harmony") meeting about one way to mitigate the unreported dead-code error that results from >function foo() { > if (some) { > if (deep) { > if (random) { > if (logic) { > if (ending) { > if (in_a_very_long) { > return > "I believe in the 80 column limit, so I wrapped"; > } > } > } > } > } > } > return "LOL"; >} The problem here is that the programmer has a legitimate reason to want to break a return across two lines and they can't. There is an easy fix for this. It's called "line continuation". In ES5 we standardized the de facto browser behavior for line continuation within string literals: LineContinuation :: \ LineTerminator Sequence. A LineContinuation certainly could also be allowed as an alternative for whitespace. Then if [no LineTerminator here] is reinterpreted to not match a LineContinuation then the above return could have been written as: return \ "I believe in the 80 column limit, so I used a LineContinuation"; It wouldn't help people who didn't know about line continuation but it would allow those who do know about them the flexibility to format their code the way they want it. I would normally say a language shouldn't need cruft like this. However, once you've go down the road of making line breaks syntactically significant it is arguably reasonable to also allow for line breaks that explicitly have no syntactic significance. Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100726/038715a9/attachment-0001.html>