tc39 / ecma262 Goto Github PK

[JP22] Foe example, step 7 of “22.1.2.1 Array.from(items [, mapfn [, thisArg ]])” is described as “Assert: items is not an Iterable so assume it is an array-like object.”. This assertion can not be interpreted as a condition.

Derived from https://bugzilla.mozilla.org/show_bug.cgi?id=1135377

ES6 21.2.2.2 steps 2.1-2 don't cover the case when index points a trails surrogate of the surrogate pair in str.

Here's testcase:

var r = /\uDC38/ug;
r.lastIndex = 1;
var str = "\uD83D\uDC38";
r.exec(str);

r.lastIndex points trail surrogate \uDC38 in str. In step 2.1, Unicode is true and Input becomes a single element list with U+1f438. So listIndex cannot point the trail surrogate character in step 2.2.

Why ecma262 lexical grammar is not a regular grammar (that can be represented as Regular Expressions)?

The leading underscores are missing at http://tc39.github.io/ecma262/#sec-object.prototype.__proto__

The following links yield 404 errors:

• TC39 RF Patent Policy
• TC39 Software Copyright Policy
• Register as a TC39 contributor

Hi,

I understand this is an ambitious request, and probably aimed at ES8 or even ES9, but considering the direction many web based technologies are heading, this request definitely makes sense in my mind.

This request is for optional, TypeScript-esque, static typing for ECMAScript.

There are tools and transpilers that already support optional static typing, and Google are also looking at supporting optional static typing directly in their virtual machine with SoundScript. That being said, a formal and specified syntax for optional static typing in ECMAScript would obviously be beneficial in numerous ways. It would allow developers to remove one or more layers from their workflow, therefore improving productivity across the board, and it would also allow virtual machines to produce highly optimized native code from the source files it consumes. I am honestly struggling to think of downsides.

I believe the time is now right to consider adding option static typing to ECMAScript. The language is evolving extremely well now, and optional static typing is one feature that is still sorely missed.

If required, I am willing to compose a full proposal to support this request.

There currently is nothing in either the spec of for-in, or the spec of proxies' [[Enumerate]] method, that would ensure that all keys are converted to a string. Consequently, a for-in over a proxy could produce arbitrary key values. That may break code that assumes it can only get strings, and is particularly strange because [[Enumerate]] on ordinary objects explicitly excludes symbols to avoid this problem.

(As a secondary consequence, the sample implementation in 9.1.11 also is broken, because if proto is a proxy, it might return equivalent keys as different values (e.g. "10" vs 10), such that their lookup in the visited set fails due to the lack of canonicalisation.)

To fix this, [[Enumerate]] on proxies probably needs to create a wrapper iterator that invokes ToString on each value returned from the trap.

In Chrome 46, we shipped a change to date formatting per ES2015 that a missing time zone should be treated as local time (where in ES5 it was treated as UTC). See https://code.google.com/p/chromium/issues/detail?id=543320 for details, in particular comment 5 (which lays out the exact difference).

Given the breakage, and that no other browsers seems to have shipped this change, it seems like the easiest thing to do would be to revert to the ES5 behavior. But I'm not sure what prompted the change in the first place, so it's hard to weigh such a change.

In the ES6 spec., there is no check that a destructuring let/const/var actually introduces any bindings.

For example:

let ;

is a syntax error, but (updated 10/22/15)

let { } = obj;

is valid syntax that does nothing (it doesn't add any new variable bindings).

There are reports that some ES6 developers are encountering bugs cause by complex destructing patterns that unintentionally don't introduce any bindings.

This seems like a design bug in ES6. It would be trivial to specify that this is an early syntax error.

In 13.3.1.1
LexicalBinding : BindingPattern Initializer
- It is a Syntax Error if the BoundNames of BindingPattern has no elements.

In 14.1.2
FormalParameter : * BindingElement*
- It is a Syntax Error if the BoundNames of BindingElement has no elements.

Note that this is a breaking change for any program that actually contains such empty binding patterns. So there is some risk to making this change.

Hi, guys! Sorry if I create some stupid or incorrect issue.

Is there any plans to look into pattern matching and currying?

Now there is no way to exit from forEach loops.

iterable.forEach(item => {
  if (item == 'what we need')
    return Symbol.breakLoop // loop breaks here
})

Traditional equivalent

for (let item of iterable) {
  if (item == 'what we need')
    break
}

Or just Symbol.break.

See https://esdiscuss.org/topic/resolve-reject-on-promise-subclasses-and-species

Update: Link to proposal: https://github.com/tc39/proposal-regexp-legacy-features

All web browsers expose non-standard properties on the RegExp constructor, that are updated each time a match is done.

The list of properties that are exposed by all common browsers are the following. They typically expose other properties not mentioned here, but not shared by all implementations:

$1, $2, $3, $4, $5, $6, $7, $8, $9,

and (in pairs, where the first and the second one return the same value):

input, $_
lastMatch, $&
lastParen, $+
leftContext, $`
rightContext, $'

Some observations:

• their value is always a string;
• some implementations expose them as data properties, others as accessor properties;
• those properties are non-enumerable;
• they cannot be deleted or modified manually.

It would be useful to specify them. I think that the following should be required:

1. Those properties should be accessors. That would be more honest about the changing nature of their value;
2. They should be deletable. Indeed, they represent global communication channels that may be unwanted in some environments;
3. It should be specified when they are updated, presumably sometime during the execution of the builtin RegExp#exec method. This is useful if we want, in some future, separate the part of RegExp#exec that does the real work, and the part that does stateful updates on various objects.

Not sure if this is a good place to ask this question. If not, I'm sorry for the noise. Could you then point me elsewhere perhaps?

I've just read this post here: http://www.2ality.com/2014/09/es6-modules-final.html
Which claims that the module system will support both sync and async loading. Which I like. But it made me wonder if/how well async loading would work for deeper dependency trees. E.g. if I had a project with 20 level deep dependency tree (at its deepest point) and my server would take on average 200ms to respond, then it would take about 4000ms minimum to execute any/all of my scripts, right? Or is there something I am missing?

If I interpret the situation correctly, what is the conceptual response to this scenario? Try to limit the tree depth? Concat everything just like it happens often with ES5? Something else?

Hey all, I was just doing some digging on do expressions and found: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-29.md#conclusionresolution-2

Conclusion/resolution

• do-expressions as generailsation of block statements
• Progresses do-expressions to the next state in the new process.

However I don't see them mentioned in the proposals table.

When for-in is invoked directly on a proxy, then it simply executes the iterator returned by the proxy handler. That prescribes a much more rigid iteration sequence than for regular objects that breaks existing implementations. In particular, implementations often want to compute the list of keys before the iteration starts, which would currently be forbidden due to observable calls to iterator.next.

This is inconsistent not just with regular objects, but also with enumeration over regular objects that have a proxy as their prototype -- because in that case the object's [[Enumerate]] still has the liberty to invoke the prototype's [[Enumerate]] whenever.

To fix this, we probably need to loosen the spec for proxy [[Enumerate]], such that it does not prescribe that the original iterator is invoked in lock-step.

9.1.1 says only that the object must be an iterator and that it must inherit from %IteratorPrototype%. Leaves me wondering:

1. Can the next property be a prototype property of the returned object?
2. Can the iterator object inherit indirectly from %IteratorPrototype%?

I would hope the answers to these are no and no. In either case, the spec text could probably be improved to clarify.

Chromium (V8) has implemented "do expression" parsing: https://chromium.googlesource.com/v8/v8/+/b6596aa73b069aaa6e52291c3756b0e0f0e483b6

I would like to read about this ES7 proposal, but I can’t find anything on the Web (ecmascript.org seems to be down). Is there a GitHub repo for this feature? If so, could you add it to the “Current proposals” table?

There are two ways that a function in ES6 can be "just a function, not a constructor":

• Use the default Function [[Construct]] method, which calls the function with the appropriate new.target, and throw an exception if new.target is undefined
• Implement only the [[Call]] internal method on a particular object, and not the [[Construct]] method. This is the strategy used for classes, and the prose at the top of the %Math% object definition also seems to imply that it is similar.

In https://code.google.com/p/v8/issues/detail?id=4538 , V8 engineers mention that there are different semantics to these two strategies: It changes whether IsConstructor is true. IsConstructor is called all over the place, but the most common callsites have implications with cross-realm access (in a way that's a bit outside of the direct ECMA spec): In places that construct, such as new or Reflect.construct, IsConstructor is called to see if an exception should be thrown.

So there are two places where an exception could be thrown, depending on the strategy: In the caller (the place where new is invoked, for example) and in the callee (the actual running constructor). This is visible in cross-realm settings because a different sort of exception will be thrown when the callee is in a different realm. In the former case, it will be the caller's realm, and in the latter case, it will be the callee's realm.

In offline discussion at the last TC39 meeting following Yehuda's call construct proposal, a few committee members discussed these two different implementations of implementing [[Call]] and [[Construct]]. The argument made was that, since Reflect.construct requires a constructor for newTarget, the distinction should be unobservable and it doesn't matter whether we go with separate [[Call]]/[[Construct]] methods or a conditional within the constructor. However, in this exception-throwing case, there appears to be a significant difference.

I bet this subtlety was entirely accidental, and that better semantics would be for the caller's realm to always throw the exception. This would give more information to users and be reasonable to implement.

Per es6-super-construct proposal, 'super()' invocation in ordinary functions always throws:

• In [[Call]] of that function 'super()' throws because 'super()' always throws on [[Call]](due to 'this' being always initialized in [[Call]])
  • In [[Construct]] of that function 'super()' throws, because ordinary functions are not "defined using a class definition that has an extends clause" so 'this' starts initialized when [[Construct]]ing.

We have a precedent already for concise methods where an occurrence of 'super()' call (DirectSuper) is an early error.
It will greatly help language usability if the same applies to ordinary functions (implementations can provide better error messages; the bugs are sure to be discovered)

HTML needs to specify a couple exotic objects. (Web IDL also needs to do so, if it ever gets updated to ES2015.) In many cases the behavior is "if flag X is set, throw. Otherwise, do what an ordinary object would do."

For a couple internal methods, there are pre-existing abstract operations we can use: OrdinaryGetOwnProperty and OrdinaryDefineOwnProperty. But for all others, there are not.

I see two potential ways we could spec such exotic objects:

1. Pull request ES to have OrdinaryXyz() abstract operation counterparts for all internal methods, and then use them: "If flag X is set, throw a TypeError. Otherwise, return OrdinarySetPrototypeOf(O, V)".
2. Try to come up with some phrasing that is sufficiently precise. E.g.: "If flag X is set, throw a TypeError. Otherwise, return the result of the same algorithm as the [SetOwnProperty] method for ordinary objects, applied to object O with argument V."

Any advice? Is there a chance (1) could clean up parts of the ES spec that are currently duplicated?

/cc @annevk @allenwb

I have found that some websites don't work properly under Annex B 3.3. When interacting with Reddit comments, there is code with the following pattern (in the global scope):

try {
  function x() { }
} catch { }

x()

x isn't hoisted at all under Annex B, but it must for compatibility with the current version of Reddit.

I could imagine the annex having a second rule, which is when a sloppy-mode block-scoped function declaration is made in the global scope, the appropriate property of the global object is also set when the function declaration is reached (unconditionally, since this actually couldn't lead to an early error). I think this would fix that website, but would it cause any other problems?

http://tc39.github.io/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors

• If the [Yield] grammar parameter is present on ArrowParameters, it is a Syntax Error if the lexical token sequence matched by CoverParenthesizedExpressionAndArrowParameterList cannot be parsed with no tokens left over using ArrowFormalParameters as the goal symbol.

The goal symbol should be ArrowFormalParameters[Yield] instead of ArrowFormalParameters.

[JP22] This is not a factual issue but a meta issue for the style of standard document:
Many contents of the NOTE for the Language seems to be specifications expressed in English rather than just an informative note. I’ve got that from notes in 13.3.2.4, 13.7.5.9, 13.10, 13.11. It looks that a subclause entitled “Summary” might be useful to guide the readers of this document.

See https://esdiscuss.org/topic/exception-type-for-invalid-operations for background. I'd like to update the definition of TypeError (currently "Indicates the actual type of an operand is different than the expected type.") to something that more accurately explains how it is used as the catch-all fallback error.

Here's some possible wordings. We can wordsmith in this issue thread then I'll do a PR:

• Indicates that something went wrong, often related to the input to a function.
• Indicates that something went wrong, often related to the input to a function or the conditions under which it was called.
• Indicates that the wrong kind of thing was directly or indirectly passed to a function.
• Indicates the actual type of an operand is different than the expected type. Also used as a generic "fallback" type of error in situations when other more specific types are not appropriate.

[JP22] In step 8-c-ii of “22.1.3.19 Array.prototype.reduceRight(callbackfn [, initialValue])”, callbackfn, which takes four arguments, called with three arguments (“«accumulator, kValue, k, »”). Need “O” at the end of parameters (e.g., «accumulator, kValue, k, O»)?

Now that the spec is distributed as a web page, it should have a favicon.

The grammar in 7.1.3.1 uses triple colons (:::), but during the html page creation it is somehow changed to single colons <emu-geq>:</emu-geq>.

@BrendanEich, maybe expand https://gist.github.com/BrendanEich/4294d5c212a6d2254703 into a repo and link it from here?

Should cast the limit parameter with ToUint32 not ToLength (as ToLength has the unfortunate effect of allowing invalid arrays).

For consistency with TDZs implied by lexical declarations ('let/const')

At least based on a cursory glance, the following statement results in a completion value of "Empty":

for (let x of returnsUndefinedOrNull()) { }

Probably need an UpdateEmpty in there.

Array has some methods which supports functional coding ,such as map,reduce..
Say I wanna do some transforming with an array and log the result :

var result=[1,2,3].map(function(v){
    return v+1;
});
console.log(result);

It'll be better if we can log the result without declaring variable result
First I think about this:

[1, 2, 3].map(function(v) {
    return v + 1;
}).some(function(v, i, a) {
    console.log(a);
    return true;
});

But this is aginst the purpose of some.
I need something like this:

Array.prototype.feed = function(callback) {
    callback(this);
};
[1, 2, 3].map(function(v) {
    return v + 1;
}).feed(function(a) {
    console.log(a);
});

In practice, we often need map / filter / reduce arrays and deal with the result. So it'will be a pleasure if array has a feed method (more than a pleasure if Object.prototype also has that:) to support more functional programming

Sorry for my poor English, Hope I can be understood:)

http://tc39.github.io/ecma262/#prod-Keyword

Windows 7, Chrome 46.0.2490.33, Firefox 42.0a2.

See https://github.com/tc39/ecma262/releases/tag/es2016-draft-20151019.

The early errors for Try/Catch names includes the following passage:

"It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block."

However, this is modified in B.3.5 to allow code of the form:

try {
  ...
} catch (e) {
  var e = 2;
}

to run without complaint, presumably for legacy compat reasons. The spec text says:

"It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block, unless that element is only bound by a VariableStatement or the VariableDeclarationList of a for statement, or the ForBinding of a for-in statement."

But this means that the following is also allowed:

try {
  ...
} catch ({stack, code}) {
  var stack = 1;
  var code = 2;
}

What's the motivation for allowing the destructured form, given that there will be no legacy concerns in that case? One could imagine the spec could instead read:

"It is a Syntax Error if any element of the BoundNames of CatchParameter also occurs in the VarDeclaredNames of Block, unless BoundNames contains a single element and that element is only bound by a VariableStatement or the VariableDeclarationList of a for statement, or the ForBinding of a for-in statement."

What should it look like?

See http://yehudakatz.com/2011/09/13/a-proposal-for-es-next-proposals/ by @wycats for some inspiration.

We don't even know who can edit it, and then we could clear up stuff like entry criteria vs. exit criteria.

There's an idiom called "self-defining functions". It usually looks like this:

var foo = function() {
  foo = ...
}

Some users (e.g., GWT, which has widely deployed compilation output all over the web), write a slightly different version, used to implement Java static {} class initialization blocks that run just once, but with checks all over the place to run it if it hasn't been run yet:

function foo() {
   foo = ...
}

Many module systems wrap all the definition code in a try/catch. Google does this internally, and the JS code in Reddit seems to have had a similar treatment. If we have a sloppy-mode block-scoped self-defining function as follows:

try {
  function foo() {
    alert("hey!")
    foo = () => {}
  }
} catch (e) { }
foo()
foo()

then (I believe) all browsers pre ES2015 (IE10-, WebKit, Firefox and Chrome) would alert "hey" just once. This is the long-standing web-compatible intersection, as far as I can tell.

However, ES2015 semantics would say that there are two bindings--the inner lexical one inside the try block, and the outer function-hoisted one. The line redefining foo will redefine the lexical binding, and leave the hoisted one in place. So "hey!" will be alerted twice. This is IE11 and Edge semantics, as the first implementors of something approximating Annex B 3.3.

I don't think these semantics are web-compatible. They break Google Inbox, though Inbox does not currently try to work on IE. More generally, the breakage is just the result of a combination of two techniques that independently work and are independently widely used--self-defining functions (through a rather odd syntax that GWT has been emitting for years), and surrounding function definitions by try/catch (which many module systems seem to do). It is, at the very least, a refactoring hazard to prohibit them together.

I think it's possible that this breaks the web even though IE11 has been shipping for a couple years because

• GWT is used in a lot of deploy-once intranet applications which might be only used on particular browsers, and might hit only old versions of IE or non-IE browsers.
• Lots of static initialization blocks could be run multiple times, and the program can still sorta get by, but that doesn't make its behavior correct.

I think the second binding, the lexical one, isn't necessary to get something working that will allow references to lexically scoped variables from hoisted functions and be within the intersection of all browsers' semantics. An alternative semantics suggested by adamk@ is to have just one var-like binding, initialized to undefined, which is set at the top of the block where the function declaration occurs to that function value. There would be no conditionality semantics, and no multiple bindings for the same variable name, so the result would be easier for both users and implementors to understand.

Consider

let P = new Proxy(Int8Array)
let a = new P

You might not have guessed, but this will throw a type error. The reason is the, um, creative way in which the %TypedArray% base constructor tries to figure out what typed array instance to create, namely, by re-traversing the prototype chain from newTarget up to itself, looking for the closest [[TypedArrayConstructorName]] internal slot -- but that will never hit the Int8Array constructor in the example above, because the algorithm (22.2.1.2.1 AllocateTypedArray) skips from the proxy to its target's prototype directly.

More generally, I argue that this semantics is fundamentally bogus. It doesn't just break proxying typed array constructors, the prototype walk also is observable through proxies in other places of the prototype chain -- which might change the very prototype chain through side effects while you go.

More importantly, it breaks a highly desirable invariant for object construction: preferably, constructing an object should only be keyed on two inputs: (1) the base constructor (for internal fields), and (2) new target (for [[Prototype]]). With the current walk, it is keyed on an arbitrarily large set of objects, plus potentially random computations. That makes optimisation much harder: even to merely decide whether we can take a fast path for construction, we already have to look at the entire prototype chain. Under this semantics, instantiating (subclassed) typed arrays is inherently penalised.

So, as we all know, prototype chain walks are a bad and utterly unreliable tool for figuring out instance relations in JavaScript. The spec should better avoid relying on it for its innards. :)

Fortunately, we could avoid it easily for typed arrays. I propose that instead of having the base constructor re-walk the prototype chain, it should take the derived typed array constructor as an argument and read the [[TypedArrayConstructorName]] slot from there. Then proxying would work just fine, and the aforementioned invariants would be maintained. It’s also simpler. While this technically is a breaking change, it is unlikely that code in the wild currently invokes the %TypedArray% base constructor directly (in part because not all browsers implement it yet), so the compatibility hazard seems neglectable.

[JP22] 15.2.2.1 Bullet 6 says "It is a Syntax Error if MouduleItemList Contains NewTarget" and I was first puzzled on what this "NewTarget" means. Isn't it more kind to just use "new . target" (in typeface)? The problem stems from the fact that identifier "NewTarget" is used in multiple ways throughout the document, and it might be difficult to resolve. However, I guess the above change will resolve the problem here. (I also noticed that a period is missing at the end of the sentence.)

This is for HTML/ES integration. HTML has a concept of script which contains a few useful pieces of information. Notably, it contains a "muted errors flag", which is set based on whether the script was retrieved in a cross-origin manner.

When performing NextJob's "implementation defined unhandled exception processing", I need to be able to retrieve the current "HTML script" given the information available to me in the ES context.

I would have thought this would be simple: I'd simply get whatever concept ES has for "script", and add a pointer between them associating "HTML script" and "ES script". Or, I could even try to get rid of "HTML script" entirely, and just store a couple things on the ES script.

But, I can't find any concept of script in ES! :(

The closest thing I can find is the top-level execution context scriptCtx created by ScriptEvaluation.

So far the best I've come up with is:

• When running script from HTML, via NextJob(ScriptEvaluationJob, ...), smuggle in the HTML script as part of the [[HostDefined]]. Then, say something like "All execution contexts created from this ScriptEvaluationJob must have a state component pointing back to the HTML script". (Apparently execution contexts are allowed to have implementation-dependent state.)
• When implementation defined unhandled exception processing happens, use "the running execution context" to retrieve the appropriate HTML script.

Does this seem vaguely legit? I don't like "all execution contexts created from".

spec.html has not <title>.

• http://tc39.github.io/ecma262/

A colophon describes the tools and resources used in the creation of a published work. Additionally, it may contain the authorship information such as who created the work, and when and where the work was created.

As an example, see the colophon from Stephen Wolfram's A New Kind of Science.

It's a lot of effort to track where the CoverInitializedName occurs, and then later determine if it's allowed to be present there.

Why not just allow it everywhere? property name = LHS, value = evaluation of RHS.

var x;
var foo = { x = 10 }; // equivalent of `var foo = { x: x = 10 }`
console.log(x) // 10
console.log(foo) // { x: 10 }

It would at simplify implementation a bit.

Maybe, if it was really necessary, it could have consistency with the behaviour of destructuring, such that

var x;
var foo = { x = 10 }; // equivalent of `var foo = { x: x === void 0 ? 10 : x }`
console.log(x) // undefined
console.log(foo) // { x: 10 }

The preface to B.3.3 lists three FiB use cases with bullets under each numbers use case. The bullets define when each use case applies. However the bullets for the second and third use cases each have the wrong bullet set. They need to be swapped.

The easiest (and I think best) fix is to leave the bullets where they are and swap the the numbered heading lines for cases 2 and 3.

(I think what happened is that I originally had only two use cases When the third was added i copied the send use case and updated the copied bullets. But then I changed the use case descript9ion line for the second set when I should have made that change for the third set).

On Jan 9, 2015, at 7:43 AM, Erik Arvidsson wrote:

Happy New Year!

(I don't know which thread is the active thread.)

https://github.com/tc39/ecma262/blob/master/workingdocs/ES6-super-construct%3Dproposal.md

Point 12: If a class definition does not include an explicit constructor definition, it defaults to: constructor(...args) {super(...args)}; if the class has a non-null extends clause. Otherwise it defaults to: constructor() {};.

This is problematic since we have to evaluate the extends expression to know if it is null or not. This means that the default constructor needs to be:

constructor(...args) {
if (%extendsValue !== null) super(...args);
}

where %extendsValue is the result of evaluating the extends expression and it has to be captured for later references.

erik

Sorry if this is the wrong place to post this (or if someone has already proposed it).

Lately I've been writing quite a bit of code which needs some things to be lazily evaluated. So far I've just been using functions with empty parameters, but having lots of empty function parameters all over the place makes things unnecessarily verbose and hard to read. Some examples of where this might happen:

// Logging a value after a specified amount of time.
setTimeout(function(){console.log("Ten seconds have passed")},10000);
setTimeout(()=>console.log("Ten seconds have passed"),10000);

// Generic library that lazily evaluates chained methods.
bigArray.map(x=x*2).filter(x=>x>10).sort((a,b)=>a-b).exec()

As you can see, a function expression with empty parameters has 10 unnecessary characters, while an arrow function with empty parameters has 4 unnecessary characters.

My first thought was to wrap expressions to be lazily evaluated in backticks, but they are now used for template strings. Perhaps putting a @ or a # before an expression wrapped in parentheses or statement wrapped in curly braces would be acceptable?

As for evaluating the expression/statement, I'd think that expression() would make sense. This would mean that if the chained methods example above was used, then the .exec() or .done() method could just be (). The examples above might then become:

setTimeout(@(console.log("Ten seconds have passed"), 10000);

bigArray.map(x=x*2).filter(x=>x>10).sort((a,b)=>a-b)()

While browsing the spec I typically end up looking for something like "[[Call]]" which exists in multiple places (Functions, Proxies...). In this case it is not always immediately clear in which section you are.

It would be nice to highlight the current super-section somehow. One option would be to show it in the expanded TOC, another one might be using fixed Breadcrumps at the top of the specs.

This would be great when breaking up strings into multiple lines in the source code. It would save us from writing a + for every line break. This is a feature present in C, Python, and Ruby. It's most useful when your style guide enforces max characters per line and you want to keep a level of indentation.

Example:

// gettext is used for translations
gettext('This is a string literal '
        'written in multiple lines');

should be transpiled to a single string.

// gettext is used for translations
gettext('This is a string literal written in multiple lines');

Other thoughts:

• An indented template string introduces multiple spaces in between words and line feed characters.
• Stripping line feeds and multiple spaces is not entirely the point. Yes we can create a function that does that, but having the interpreter/compiler handle the concatenation should be more performant and the strings can be statically analyzed by tools (linting, makemessages)