top-level return does not cause ParseError #4

Activity

1. ArtskydJ commented on Jan 27, 2016

   

   ArtskydJ

   on Jan 27, 2016

   More actions

   I don't see an issue here.

   C:\Users\Michael\Github\JS_Source>echo return>return.js
   
   C:\Users\Michael\Github\JS_Source>node return.js
   
   C:\Users\Michael\Github\JS_Source>
   

   Seems ok on the browser too: https://jsfiddle.net/a32b1nas/1/
2. michaelficarra commented on Jan 27, 2016

   

   michaelficarra

   on Jan 27, 2016

   Author

   More actions

   1. node is wrapping your code in an IIFE, which breaks many things. See program code is not run in global execution context nodejs/node-v0.x-archive#6254
   2. JSFiddle is wrapping your code in a function as well:

   <script type="text/javascript">//<![CDATA[
   window.onload=function(){
   console.log('here goes')
   return
   console.log('you will not see this')
   }//]]> 
   </script>
3. ArtskydJ commented on Jan 27, 2016

   

   ArtskydJ

   on Jan 27, 2016

   More actions

   The JSfiddle was a bad example, sorry.

   ---

   I still think this issue is invalid. This module is looking for a syntax error in a code string. This code string should not be presumed to be in the top-level context.

   If I gave this string...

   helloWorld()
   return arguments[2]

   ...to this module, I would not expect to be given an error, even though in this code string helloWorld and arguments are undefined. Those would be runtime errors, not syntax errors. There is nothing syntactically incorrect in that code string.

   Does that make sense?
4. michaelficarra commented on Jan 27, 2016

   

   michaelficarra

   on Jan 27, 2016

   Author

   More actions

   Take a look at the ECMAScript grammar. Trust me, top level returns are a syntax error, not a runtime error.
5. ArtskydJ commented on Jan 27, 2016

   

   ArtskydJ

   on Jan 27, 2016

   More actions

   Yeah, but my argument is that the provided code string should not be assumed to be top-level. The code string could hypothetically be part of a function.
6. mattdesl commented on Jan 27, 2016

   

   mattdesl

   on Jan 27, 2016

   Collaborator

   More actions

   @ArtskydJ I think it depends on use case. For browserify (and my own app devtool) the assumption is the source is not top-level (wrapped in Node's closure).

   Perhaps it could be configurable in a third opts parameter.

   EDIT: Updated wording.
7. ArtskydJ commented on Jan 27, 2016

   

   ArtskydJ

   on Jan 27, 2016

   More actions

   @mattdesl That's true. Since a return statement is a SyntaxError in some cases, ideally it should be configurable.

   Just like the code string shouldn't be assumed to be top-level, it shouldn't be assumed to be non-top-level either.