Fixing ASI, as desirable as that may be, is not going to
happen soon. Neither is the transition going to be quick
if/when a better alternative emerges, as existing ASI usage
patterns need to be supported.
However, these usage patterns are currently not clearly
identified - there seem to be multiple schools of ASI usage,
with different needs and intentions, and implementations
cannot guess intentions.
Idea:
Start by giving javascript programmers the ability to declare
their intentions wrt ASI usage. That way, future attempts at
ASI improvements will have a better handle on what they
need to preserve, and what they can change.
Even without ASI changes, such declarations will allow
implementations to give better warnings (no need to guess
user intentions), helping to avoid current ASI pitfalls.
Suggestion (outline; syntax and details up for discussion):
Introduce a language pragma for ASI, accompanied by
warning pragmas (a "language pragma" indicates use of a
language feature, as a modular alternative to language
versions; a "warning pragma" indicates use of an
implementation option).
Lacking a javascript standard for pragmas, this suggestion
follows the "use strict" example (string expression statements
with function or script scope):
Language pragma:
"ASI:on"; // to indicate maximal use of ASI
"ASI:off"; // to indicate minimal use of ASI
Warning pragmas:
"ASI:warn-insert:[on/off]";
// warn about unexpected semicolon insertion
"ASI:warn-no-insert:[on/off]";
// warn about missing semicolons
(examples of "unexpected"/"missing" are given below)
Implied warnings:
The default for ASI warnings is "off" (no warnings).
Use of "ASI:on" shall imply "ASI:warn-no-insert:on".
Use of "ASI:off" shall imply "ASI:warn-insert:on".
Implied warnings can be reset by explicit warning
pragmas.
Phase 1: (the current suggestion; as soon as possible)
Implementations supporting ASI pragmas must run code
*with or without* ASI pragmas as before, but must provide
checks and warnings (on a side channel, such as an error
console) for code *with* ASI pragmas.
Phase 2: (depending on implementer/programmer buy-in
to phase 1; probably not anytime soon)
Implementations supporting ASI pragmas must run code
*without* ASI pragmas as before, but could treat ASI
warnings for code *with* ASI pragmas as errors.
One could also start to issue deprecation warnings for
code without ASI pragmas, encouraging transition to
ASI usage pattern documentation, and one could evaluate
ASI usage patterns, as declared by use of ASI pragmas in
real-world code.
Warning-free code with ASI pragmas should both offer
good test-cases for any ASI modifications and document
programmer intentions for any transition support tools.
Observations and clarifications:
As far as I can tell from the previous ASI thread, there are several
groups with opinions about ASI, including (but not limited to):
A those who avoid semicolons, relying on ASI to fill them in
B those who avoid ASI, writing out all semicolons explicitly
C those who expect newlines to imply semicolons, with mixed
results, because that isn't the way ASI works
These groups have different problems with ASI, even assuming
that both A and B know and understand how ASI works:
A have to insert semicolons where ASI does not kick in
B have to be wary of ASI inserting unwanted semicolons
C tend to find ASI confusing
As long as we don't have a better solution, it seems that warning
about the unexpected/unwanted might improve understanding
and user experience of ASI as it stands. This should also prepare
the ground for any ASI improvements/replacements.
Currently, implementations cannot issue warnings - they are
handling ASI as specified and they cannot guess whether or not
that matches programmer intentions; however, once programmers
declare their ASI usage pattern (maximal/minimal), there are two
well-known trouble spots that can trigger warnings.
Both of these trouble spots are related to newlines (either the
programmer expects a newline to insert a semicolon, but ASI
does not apply, or the programmer expects no inserted
semicolons, but ASI is triggered by a newline):
(a) warn if two consecutive statement lines of equal indentation
are not separated by explicit or inserted semicolon
(b) warn if restricted production or error correction insert
semicolon at a newline that is followed by extra indent
For warnings to be useful, it must be possible for coders to
avoid them on a case-by-case basis, without disabling the
warning entirely - this is here supported based on the idea
of indentation (only used for controlling these warnings):
a can be silenced by having the next line indented further,
to indicate continuation of statement on previous line
b can be silenced by having the next line indented equally,
to indicate start of new statement
The choice of indentation for warning control is intentional,
as it will offer feedback on whether a significant whitespace
approach to semicolon insertion would work for Javascript
developers, without going all the way towards introducing
such a change (although ASI already is whitespace-dependent,
via newlines).
Warning (a) should be included in "ASI:warn-no-insert",
warning (b) should be included in "ASI:warn-insert". It might
be possible to include warnings for other pitfalls, if they can
be identified and silenced unambiguously.
The warnings should be opt-in (by pragma), and on a side
channel (like HTML/CSS parser errors), visible to developers
and interested users, but not to viewers only interested in
content. Group A will want to use "ASI:on", and get some
help with missing semicolons, group B will want to use
"ASI:off", and get some help with unwanted semicolons,
group C might be helped by using both warnings.
Does this sound useful to all parties?
Claus
// examples
function restricted_production() {
"ASI:off";
return //;
"hi"; // warn here, provided this line is indented
}
function newline_no_asi() {
"ASI:on";
var x = ["hi"] //;
[1]; // warn here, unless this line is indented
return x;
}
function newline_error_asi() {
"ASI:warn-insert";
var a = "hi"+
"ho";
var b = "hi" //;
"ho"; // warn here, provided this line is indented
return a==="hiho" && b==="hi";
}
log( restricted_production() ||
"newline in restricted production inserts semicolon" );
log( newline_no_asi() ||
"newline alone does not insert semicolon" );
log( newline_error_asi() &&
"newline followed by error inserts semicolon" )
/*
suggestions:
warn if inserted semicolon is followed by indented line
warn if non-indented line is not preceded by implicit or explicit
semicolon
*/
Background assumptions:
Fixing ASI, as desirable as that may be, is not going to
happen soon. Neither is the transition going to be quick
if/when a better alternative emerges, as existing ASI usage
patterns need to be supported.
However, these usage patterns are currently not clearly
identified - there seem to be multiple schools of ASI usage,
with different needs and intentions, and implementations
cannot guess intentions.
Idea:
Start by giving javascript programmers the ability to declare
their intentions wrt ASI usage. That way, future attempts at
ASI improvements will have a better handle on what they
need to preserve, and what they can change.
Even without ASI changes, such declarations will allow
implementations to give better warnings (no need to guess
user intentions), helping to avoid current ASI pitfalls.
Suggestion (outline; syntax and details up for discussion):
Introduce a language pragma for ASI, accompanied by
warning pragmas (a "language pragma" indicates use of a
language feature, as a modular alternative to language
versions; a "warning pragma" indicates use of an
implementation option).
Lacking a javascript standard for pragmas, this suggestion
follows the "use strict" example (string expression statements
with function or script scope):
Language pragma:
"ASI:on"; // to indicate maximal use of ASI
"ASI:off"; // to indicate minimal use of ASI
Warning pragmas:
"ASI:warn-insert:[on/off]";
// warn about unexpected semicolon insertion
"ASI:warn-no-insert:[on/off]";
// warn about missing semicolons
(examples of "unexpected"/"missing" are given below)
Implied warnings:
The default for ASI warnings is "off" (no warnings).
Use of "ASI:on" shall imply "ASI:warn-no-insert:on".
Use of "ASI:off" shall imply "ASI:warn-insert:on".
Implied warnings can be reset by explicit warning
pragmas.
Phase 1: (the current suggestion; as soon as possible)
Implementations supporting ASI pragmas must run code
*with or without* ASI pragmas as before, but must provide
checks and warnings (on a side channel, such as an error
console) for code *with* ASI pragmas.
Phase 2: (depending on implementer/programmer buy-in
to phase 1; probably not anytime soon)
Implementations supporting ASI pragmas must run code
*without* ASI pragmas as before, but could treat ASI
warnings for code *with* ASI pragmas as errors.
One could also start to issue deprecation warnings for
code without ASI pragmas, encouraging transition to
ASI usage pattern documentation, and one could evaluate
ASI usage patterns, as declared by use of ASI pragmas in
real-world code.
Warning-free code with ASI pragmas should both offer
good test-cases for any ASI modifications and document
programmer intentions for any transition support tools.
Observations and clarifications:
As far as I can tell from the previous ASI thread, there are several
groups with opinions about ASI, including (but not limited to):
A those who avoid semicolons, relying on ASI to fill them in
B those who avoid ASI, writing out all semicolons explicitly
C those who expect newlines to imply semicolons, with mixed
results, because that isn't the way ASI works
These groups have different problems with ASI, even assuming
that both A and B know and understand how ASI works:
A have to insert semicolons where ASI does not kick in
B have to be wary of ASI inserting unwanted semicolons
C tend to find ASI confusing
As long as we don't have a better solution, it seems that warning
about the unexpected/unwanted might improve understanding
and user experience of ASI as it stands. This should also prepare
the ground for any ASI improvements/replacements.
Currently, implementations cannot issue warnings - they are
handling ASI as specified and they cannot guess whether or not
that matches programmer intentions; however, once programmers
declare their ASI usage pattern (maximal/minimal), there are two
well-known trouble spots that can trigger warnings.
Both of these trouble spots are related to newlines (either the
programmer expects a newline to insert a semicolon, but ASI
does not apply, or the programmer expects no inserted
semicolons, but ASI is triggered by a newline):
(a) warn if two consecutive statement lines of equal indentation
are not separated by explicit or inserted semicolon
(b) warn if restricted production or error correction insert
semicolon at a newline that is followed by extra indent
For warnings to be useful, it must be possible for coders to
avoid them on a case-by-case basis, without disabling the
warning entirely - this is here supported based on the idea
of indentation (*only* used for controlling these warnings):
a can be silenced by having the next line indented further,
to indicate continuation of statement on previous line
b can be silenced by having the next line indented equally,
to indicate start of new statement
The choice of indentation for warning control is intentional,
as it will offer feedback on whether a significant whitespace
approach to semicolon insertion would work for Javascript
developers, without going all the way towards introducing
such a change (although ASI already is whitespace-dependent,
via newlines).
Warning (a) should be included in "ASI:warn-no-insert",
warning (b) should be included in "ASI:warn-insert". It might
be possible to include warnings for other pitfalls, if they can
be identified and silenced unambiguously.
The warnings should be opt-in (by pragma), and on a side
channel (like HTML/CSS parser errors), visible to developers
and interested users, but not to viewers only interested in
content. Group A will want to use "ASI:on", and get some
help with missing semicolons, group B will want to use
"ASI:off", and get some help with unwanted semicolons,
group C might be helped by using both warnings.
Does this sound useful to all parties?
Claus
// examples
function restricted_production() {
"ASI:off";
return //;
"hi"; // warn here, provided this line is indented
}
function newline_no_asi() {
"ASI:on";
var x = ["hi"] //;
[1]; // warn here, unless this line is indented
return x;
}
function newline_error_asi() {
"ASI:warn-insert";
var a = "hi"+
"ho";
var b = "hi" //;
"ho"; // warn here, provided this line is indented
return a==="hiho" && b==="hi";
}
log( restricted_production() ||
"newline in restricted production inserts semicolon" );
log( newline_no_asi() ||
"newline alone does not insert semicolon" );
log( newline_error_asi() &&
"newline followed by error inserts semicolon" )
/*
* suggestions:
* - warn if inserted semicolon is followed by indented line
* - warn if non-indented line is not preceded by implicit or explicit
semicolon
*/
Background assumptions:
Idea:
Suggestion (outline; syntax and details up for discussion):
Observations and clarifications:
As far as I can tell from the previous ASI thread, there are several groups with opinions about ASI, including (but not limited to):
A those who avoid semicolons, relying on ASI to fill them in B those who avoid ASI, writing out all semicolons explicitly C those who expect newlines to imply semicolons, with mixed results, because that isn't the way ASI works
These groups have different problems with ASI, even assuming that both A and B know and understand how ASI works:
A have to insert semicolons where ASI does not kick in B have to be wary of ASI inserting unwanted semicolons C tend to find ASI confusing
As long as we don't have a better solution, it seems that warning about the unexpected/unwanted might improve understanding and user experience of ASI as it stands. This should also prepare the ground for any ASI improvements/replacements.
Currently, implementations cannot issue warnings - they are handling ASI as specified and they cannot guess whether or not that matches programmer intentions; however, once programmers declare their ASI usage pattern (maximal/minimal), there are two well-known trouble spots that can trigger warnings.
Both of these trouble spots are related to newlines (either the programmer expects a newline to insert a semicolon, but ASI does not apply, or the programmer expects no inserted semicolons, but ASI is triggered by a newline):
(a) warn if two consecutive statement lines of equal indentation are not separated by explicit or inserted semicolon (b) warn if restricted production or error correction insert semicolon at a newline that is followed by extra indent
For warnings to be useful, it must be possible for coders to avoid them on a case-by-case basis, without disabling the warning entirely - this is here supported based on the idea of indentation (only used for controlling these warnings):
a can be silenced by having the next line indented further, to indicate continuation of statement on previous line b can be silenced by having the next line indented equally, to indicate start of new statement
The choice of indentation for warning control is intentional, as it will offer feedback on whether a significant whitespace approach to semicolon insertion would work for Javascript developers, without going all the way towards introducing such a change (although ASI already is whitespace-dependent, via newlines).
Warning (a) should be included in "ASI:warn-no-insert", warning (b) should be included in "ASI:warn-insert". It might be possible to include warnings for other pitfalls, if they can be identified and silenced unambiguously.
The warnings should be opt-in (by pragma), and on a side channel (like HTML/CSS parser errors), visible to developers and interested users, but not to viewers only interested in content. Group A will want to use "ASI:on", and get some help with missing semicolons, group B will want to use "ASI:off", and get some help with unwanted semicolons, group C might be helped by using both warnings.
Does this sound useful to all parties? Claus
// examples
function restricted_production() { "ASI:off"; return //; "hi"; // warn here, provided this line is indented }
function newline_no_asi() { "ASI:on"; var x = ["hi"] //; [1]; // warn here, unless this line is indented return x; }
function newline_error_asi() { "ASI:warn-insert"; var a = "hi"+ "ho"; var b = "hi" //; "ho"; // warn here, provided this line is indented return a==="hiho" && b==="hi"; }
log( restricted_production() || "newline in restricted production inserts semicolon" ); log( newline_no_asi() || "newline alone does not insert semicolon" ); log( newline_error_asi() && "newline followed by error inserts semicolon" )
/*
Background assumptions: Fixing ASI, as desirable as that may be, is not going to happen soon. Neither is the transition going to be quick if/when a better alternative emerges, as existing ASI usage patterns need to be supported. However, these usage patterns are currently not clearly identified - there seem to be multiple schools of ASI usage, with different needs and intentions, and implementations cannot guess intentions. Idea: Start by giving javascript programmers the ability to declare their intentions wrt ASI usage. That way, future attempts at ASI improvements will have a better handle on what they need to preserve, and what they can change. Even without ASI changes, such declarations will allow implementations to give better warnings (no need to guess user intentions), helping to avoid current ASI pitfalls. Suggestion (outline; syntax and details up for discussion): Introduce a language pragma for ASI, accompanied by warning pragmas (a "language pragma" indicates use of a language feature, as a modular alternative to language versions; a "warning pragma" indicates use of an implementation option). Lacking a javascript standard for pragmas, this suggestion follows the "use strict" example (string expression statements with function or script scope): Language pragma: "ASI:on"; // to indicate maximal use of ASI "ASI:off"; // to indicate minimal use of ASI Warning pragmas: "ASI:warn-insert:[on/off]"; // warn about unexpected semicolon insertion "ASI:warn-no-insert:[on/off]"; // warn about missing semicolons (examples of "unexpected"/"missing" are given below) Implied warnings: The default for ASI warnings is "off" (no warnings). Use of "ASI:on" shall imply "ASI:warn-no-insert:on". Use of "ASI:off" shall imply "ASI:warn-insert:on". Implied warnings can be reset by explicit warning pragmas. Phase 1: (the current suggestion; as soon as possible) Implementations supporting ASI pragmas must run code *with or without* ASI pragmas as before, but must provide checks and warnings (on a side channel, such as an error console) for code *with* ASI pragmas. Phase 2: (depending on implementer/programmer buy-in to phase 1; probably not anytime soon) Implementations supporting ASI pragmas must run code *without* ASI pragmas as before, but could treat ASI warnings for code *with* ASI pragmas as errors. One could also start to issue deprecation warnings for code without ASI pragmas, encouraging transition to ASI usage pattern documentation, and one could evaluate ASI usage patterns, as declared by use of ASI pragmas in real-world code. Warning-free code with ASI pragmas should both offer good test-cases for any ASI modifications and document programmer intentions for any transition support tools. Observations and clarifications: As far as I can tell from the previous ASI thread, there are several groups with opinions about ASI, including (but not limited to): A those who avoid semicolons, relying on ASI to fill them in B those who avoid ASI, writing out all semicolons explicitly C those who expect newlines to imply semicolons, with mixed results, because that isn't the way ASI works These groups have different problems with ASI, even assuming that both A and B know and understand how ASI works: A have to insert semicolons where ASI does not kick in B have to be wary of ASI inserting unwanted semicolons C tend to find ASI confusing As long as we don't have a better solution, it seems that warning about the unexpected/unwanted might improve understanding and user experience of ASI as it stands. This should also prepare the ground for any ASI improvements/replacements. Currently, implementations cannot issue warnings - they are handling ASI as specified and they cannot guess whether or not that matches programmer intentions; however, once programmers declare their ASI usage pattern (maximal/minimal), there are two well-known trouble spots that can trigger warnings. Both of these trouble spots are related to newlines (either the programmer expects a newline to insert a semicolon, but ASI does not apply, or the programmer expects no inserted semicolons, but ASI is triggered by a newline): (a) warn if two consecutive statement lines of equal indentation are not separated by explicit or inserted semicolon (b) warn if restricted production or error correction insert semicolon at a newline that is followed by extra indent For warnings to be useful, it must be possible for coders to avoid them on a case-by-case basis, without disabling the warning entirely - this is here supported based on the idea of indentation (*only* used for controlling these warnings): a can be silenced by having the next line indented further, to indicate continuation of statement on previous line b can be silenced by having the next line indented equally, to indicate start of new statement The choice of indentation for warning control is intentional, as it will offer feedback on whether a significant whitespace approach to semicolon insertion would work for Javascript developers, without going all the way towards introducing such a change (although ASI already is whitespace-dependent, via newlines). Warning (a) should be included in "ASI:warn-no-insert", warning (b) should be included in "ASI:warn-insert". It might be possible to include warnings for other pitfalls, if they can be identified and silenced unambiguously. The warnings should be opt-in (by pragma), and on a side channel (like HTML/CSS parser errors), visible to developers and interested users, but not to viewers only interested in content. Group A will want to use "ASI:on", and get some help with missing semicolons, group B will want to use "ASI:off", and get some help with unwanted semicolons, group C might be helped by using both warnings. Does this sound useful to all parties? Claus // examples function restricted_production() { "ASI:off"; return //; "hi"; // warn here, provided this line is indented } function newline_no_asi() { "ASI:on"; var x = ["hi"] //; [1]; // warn here, unless this line is indented return x; } function newline_error_asi() { "ASI:warn-insert"; var a = "hi"+ "ho"; var b = "hi" //; "ho"; // warn here, provided this line is indented return a==="hiho" && b==="hi"; } log( restricted_production() || "newline in restricted production inserts semicolon" ); log( newline_no_asi() || "newline alone does not insert semicolon" ); log( newline_error_asi() && "newline followed by error inserts semicolon" ) /* * suggestions: * - warn if inserted semicolon is followed by indented line * - warn if non-indented line is not preceded by implicit or explicit semicolon */