The link for "Formal specification" in README file seems to be broken and the server responds with 404:

The current syntax

SimpleMemberExpression[Yield, Await] :
  IdentifierReference[?Yield, ?Await]
  SimpleMemberExpression[?Yield, ?Await] . IdentifierName
  ( Expression[+In, ?Yield, ?Await] )

disallows o.#p as a simple member expression, instead one would have to parenthesize it into (o.#p).

Is it intentional? From users's perspective, I would expect it suffices to replace .foo with .#foo when transitioning from a public property to a private one.

I need to integrate this old Gist that compares this proposal with @hax’s Stage-1 Extensions proposal. There are a few problems with the Gist, too.

The biggest problem is, as per the Matrix discussion from two days ago and also discussion in #8, the document focuses too much on the security use case.

I’m going to redo this document to focus more on the general frequency of bind/call and how clunky they currently are.

The readme gives as the sole motivation for this proposal the desire to be defensive against mutation of Function.prototype.

I don't find this motivation nearly compelling enough to justify new syntax. If you want to run in an untrusted environment already need to be saving any other prototype methods, as the readme notes, even given this syntax:

// Our own trusted code, running before any adversary.
const { slice } = Array.prototype;

Once you're doing that, the additional overhead of saving the various Function.prototype methods is negligible. That is, code which wants to be defensive can (and indeed generally does) already write

const { bind, call } = Function.prototype;
const uncurryThis = bind.bind(call);
const slice = uncurryThis(Array.prototype.slice);

// [...]

delete Array.prototype.slice;
delete Function.prototype.call;

// [...]

slice([0, 1, 2], 1, 2); // works fine

So it seems to me that this syntax does relatively little to improve this relatively obscure use case. As such, it doesn't seem to me to even approach the bar for adding new syntax, at least not on the strength of the motivations given in the readme. Are there other motivations?

At the Committee plenary today, @waldemarhorwat expressed concern that (from my memory, might be incorrect) a.b?.c::fn is ambiguous.

I’m not sure where the ambiguity comes from yet. a.b?.c::fn is equivalent to (a.b?.c)::fn. The specification has an OptionalChain :: OptionalChain :: SimpleMemberExpression production, and a.b?.c::fn should be:

• OptionalExpression:
  • MemberExpression: a.b
  • OptionalChain:
    • OptionalChain:
      • ?.
      • IdentifierName: c
    • ::
    • SimpleMemberExpression: fn

But I may well be missing something.

I am seeking real-world examples of code that would be improved by a syntactic this-bind operator.

According to @ljharb and @bmeck, Node contains many methods that bind various intrinsic global methods in order to avoid being affected by external prototype pollution. @bmeck gives this example in tc39/proposal-extensions#11:

// instead of
const slice = Function.prototype.call.bind(Array.prototype.slice);

function copyArray(arr) {
  return slice(arr);
}

// The adversary’s external code.
delete Array.prototype.slice;
delete Function.prototype.call;

// Our own trusted code, running later.
// In spite of the adversary’s code, this does not throw an error.
copyArray(arr);

…which in this proposal would be improved to:

// Our own trusted code, running before any adversary.
const { slice } = Array.prototype;

function copyArray(arr) {
  return arr->slice();
}

// The adversary’s external code.
delete Array.prototype.slice;
delete Function.prototype.call;

// Our own trusted code, running later.
// In spite of the external code, this does not throw an error.
copyArray(arr);

Where in Node.js (or elsewhere) does this pattern actually occur? We need to transplant examples from them into the explainer.

Please correct me if I am wrong, but my understanding of this proposal has me thinking that the real power of it is the extension function capability, as it would allow for libraries like rxjs and other functional libraries to provide free functions (that are tree shakeable) that operate on this. Additionally, it works well as a local builder pattern for a foreign object.

RxJS example:

Before

const searchResults$ = fromEvent(document.querySelector('input'), 'input').pipe(
  map(event => event.target.value),
  filter(searchText => searchText.length > 2),
  debounce(300),
  distinctUntilChanged(),
  switchMap(searchText => queryApi(searchText).pipe(retry(3))),
  share(),
)

After

const searchResults$ = fromEvent(document.querySelector('input'), 'input')
  -> map(event => event.target.value)
  -> filter(searchText => searchText.length > 2)
  -> debounce(300)
  -> distinctUntilChanged()
  -> switchMap(searchText => queryApi(searchText).pipe(retry(3)))
  -> share()

where a function like map has the signature

function map<T, R>(this: Observable<T>, project: (value: T, index: number) => R): Observable<R> {
  // ...
}

Builder example:

// imagine this class is external library code
class UrlBuilder {

   constructor(url) {
     this.url = new URL(url)
   }

   build(): string {
     return this.url.toString()
   }
   
	setHost(host: string): this {
       this.url.host = host;
       return this;
    }

}

// and our own local code provides extensions to it
function toUrlBuilder(this: string): UrlBuilder {
   return new UrlBuilder(this);
}

function addQueryParam(this: UrlBuilder, name: string, value: string): UrlBuilder {
   this.url.searchParams.append(name, value);
   return this
}

then we can use the proposed bind syntax to augment the existing library with our new function in a fluent chaining way

const url: string = "https://github.com/js-choi/proposal-bind-operator" -> toUrlBuilder() // local extension 
.setHost("google.com") // external library member
->addQueryParam("s", "TC39 bind proposal") // local extension
.build() // external library member

I feel like this addresses a number of the concerned use cases around the Hack style pipeline operator

We probably should allow a.b?.::c(), like how we allow a.b?.c() and a.b?.(). I will amend the specification later.

The .push usage statistics in the explainer are off by one missing digit. (Noticed by @bakkot.)

The current explainer expects the RHS of :: to be either:

• an Identifier
• a ParenthesizedExpression

This works well for existing variables like this:

import { fn } from "foo";
obj::fn

But seems to require excess ceremony when used with module namespace imports:

import * as foo from "foo";
obj::foo.fn // syntax error
obj::(foo.fn) // ok

It would be nice to support a dotted name, especially since there are some methods built into the JS core API that intentionally support tear-offs (i.e., Array.prototype.*):

obj::Array.prototype.map
obj::Array.prototype.filter

I was thinking about how :: is meant to be analogous to ., but realized this proposal currently only covers the "dot-call" version of the operator, foo.bar(). It leaves out the getter/setter invocation behavior of plain foo.bar. Should we consider this?

(I won't speculate on mechanics of it right now - we'd have to be slightly creative to get it to work, since there's no way to define a "free getter" like you can free function. Probably a symbol on the bar object or something could work.)

This would allow syntax like foo::bar = 1, or even chained foo::bar::baz = 1 (invoking the "bar" getter-fn with "foo", then the "baz" setter-fn on that result). This would let you ergonomically handle WeakMaps-as-Ephemerons, for example: foo::bar could translate to bar.get(foo), and foo::bar = 1 to bar.set(foo, 1).

Even if we don't want to do it right now, should we consider it as a likely future extension? This would imply, most importantly, that the RHS of the :: operator is an ident (or parenthesized expression), so things like foo::bar.baz() would parse as (foo::bar).baz(), not foo::(bar.baz)().

Let me share my work of implementing call-this operator to TypeScript. It includes rough type check of receivers using this parameter. Any feedback is welcome.

Hope this helps the proposal to be proceed.

microsoft/TypeScript#58294

@acutmore pointed out in Matrix a few days ago that the explainer does not address the differences this proposal has with the old Stage-0 bind proposal.

In fact, this should be the top thing that the explainer does: it’s a simplified resurrection of the old bind proposal, and it should compare and contrast itself with the old bind proposal (and with the Stage-1 Extensions proposal; see #9).

This was stubbed out in fc74301. Still need to finish.

For context, I'll be heavily relying on the pipeline operator proposal here.

I know this proposal is in its very early stages, and the details aren't even finalized, but I've been trying to also think about the use case for the bind operator, and trying to see if there's perhaps a better way to solve this problem. And, I think I found an interesting solution.

Let's start by saying we have a new Object.methodToFunction() function (whether we actually add this or not can be debated, but it makes for a good stepping stone to what comes next). We can define it roughly as follows:

Object.methodToFunction = function (method) {
  // In the actual definition, it won't be suseptable to `delete Function.prototype.call` issues.
  return (thisArg, ...args) => method.call(thisArg, ...args)
}

// Usage

const map = Object.methodToFunction(Array.prototype.map)
;[2, 3]
  |> map(^, x => x + 1)
  |> console.log(^) // [3, 4]

Are we on the same page thus far? Object.methodToFunction will basically just take a method that's intended to be called with a this arg, and turn it into a function who's this arg becomes the first parameter.

OK, now let's define Object.methodsToFunctions():

Object.methodsToFunctions = function (prototype) {
  return Object.entries(prototype)
    |> ^.map(([key, value]) => [key, Object.methodToFunction(value)])
    |> Object.fromEntries(^)
}

// Usage example #1

const { map, filter } = Object.methodsToFunctions(Array.prototype)

;[2, 3]
  |> map(^, x => x + 1)
  |> filter(^, x => x % 2 === 0)
  |> console.log(^) // [4]

// Usage example #2

const $Array = Object.methodsToFunctions(Array.prototype)

;[2, 3]
  |> $Array.map(^, x => x + 1)
  |> $Array.filter(^, x => x % 2 === 0)
  |> console.log(^) // [4]

Now that's pretty nice, isn't it? It fully protects against prototype mutations, while providing people with a very simple-to-use API. I could see people wanting to use this even if they don't care about prototype mutations.

https://github.com/tc39/proposal-bind-this/blob/d4c578ace8f90888a02f7425b83c6661e3c94bc0/README.md?plain=1#L155

.bind and .call are arguably three of the most commonly used functions in all JavaScript.

I assume that should be two rather than three. Before 5314119, that sentence was

.bind, .call, and .apply are arguably three of the most commonly used functions in all JavaScript.

In tc39/proposal-extensions#11, @bmeck wrote the following:

i think the bind operator changes the general flow and are bigger refactors from normal JS workflows and don't necessarily have the path towards dealing with protocols that [the Extensions] proposal does.

other bind proposals take an expression and bind the values within that expression. [The Extensions] proposal allows dispatch to match the normal receiver of an expression during invocation using a value not on the receiver. Other bind proposals do not allow lexical receivers in normal JS position and instead use currying.

Because this repository is meant as a simplified successor to the old bind-operator proposal and as an alternative to tc39/proposal-extensions, I opened an issue here.

Having said that, I am not quite sure I understand the quoted concerns. This proposal works with symbol-based protocols. And, in this proposal, no arguments (other than the this value) are bound.

Either of these would simply work:

y->(Array.prototype[Symbol.iterator])();

const $arrayIteratorFn = Array.prototype[Symbol.iterator];
y->$arrayIteratorFn();

CC: @ljharb

This proposal's README states the reason we need this bind operator is because:

.bind, .call, and .apply are very useful and very common in JavaScript codebases.
But .bind, .call, and .apply are clunky and unergonomic.

It goes on to do an excellent job at explaining both of these points.

I was curious as to the reason why the .bind() family of functions was used so often, so I decided to look into each example the proposal presented to figure out why the code authors chose to use a bind function there. Here's my findings:

Update: To preserve context for what I'm talking about, here's the code snippets from the README I was originally referring to. It's comparing how current code looks like, and how it would look like if it used the proposed bind syntax.

// [email protected]/index.js
type = toString.call(val);
type = val::toString();

// [email protected]/src/common.js
match = formatter.call(self, val);
match = self::formatter(val);

createDebug.formatArgs.call(self, args);
self::(createDebug.formatArgs)(args);

// [email protected]/errors-browser.js
return _Base.call(this, getMessage(arg1, arg2, arg3)) || this;
return this::_Base(getMessage(arg1, arg2, arg3)) || this;

// [email protected]/lib/_stream_readable.js
var res = Stream.prototype.on.call(this, ev, fn);
var res = this::(Stream.prototype.on)(ev, fn);

var res = Stream.prototype.removeAllListeners.apply(this, arguments);
var res = this::(Stream.prototype.removeAllListeners)(...arguments);

// [email protected]/lib/middleware.js
Array.prototype.push.apply(globalMiddleware, callback)
globalMiddleware::(Array.prototype.push)(...callback)

// [email protected]/lib/command.js
[].push.apply(positionalKeys, parsed.aliases[key])
positionalKeys::([].push)(parsed.aliases[key])

// [email protected]/build-es5/index.js
var code = fn.apply(colorConvert, arguments);
var code = colorConvert::fn(...arguments);

// [email protected]/q.js
return value.apply(thisp, args);
return thisp::value(...args);

// [email protected]/src/internal/operators/every.ts
result = this.predicate.call(this.thisArg, value, this.index++, this.source);
result = this.thisArg::(this.predicate)(value, this.index++, this.source);

// [email protected]/js/release/synchronous_inspection.js
return isPending.call(this._target());
return this._target()::isPending();

var matchesPredicate = tryCatch(item).call(boundTo, e);
var matchesPredicate = boundTo::(tryCatch(item))(e);

// [email protected]/polyfills.js
return fs$read.call(fs, fd, buffer, offset, length, position, callback)
return fs::fs$read(fd, buffer, offset, length, position, callback)

The "kind-of" package uses .call() because they want to call Object.prototype.toString() on a passed-in object, and they're following the good practice of not trusting that .toString() will be present and well-behaved on the passed-in object (e.g. the object could have a null prototype).

There were two examples of .call() from the "debug" package. In both scenarios, they're binding "this" to a custom object, in order to provide additional context for that function. In the first scenario, they're binding "this" while calling a user-provided function - this seems to be an undocumented feature. In the second scenario, they're only binding "this" to internal callbacks.

The "readable-stream"'s usage of .call() is actually pretty irrelevant to this proposal. It's the result of a babel transformation, turning class syntax with super calls into functions and prototypes, with .call() being used to help emulate super().

The "yargs" package was just trying to do what we can do today with the spread operator. The code must have been written before the spread operator existed.

It was a little difficult to follow the pretty-format's code. if anyone else wants to give it a shot, feel free. I think ultimately they were trying to do a form of method extraction from one of their third-party libraries, but they were binding the "this" value at a different location from where they were extracting the methods. From my initial impression, it looked like they might even be binding the wrong "this" value to these methods, but the third-party library didn't care, because the third-party library doesn't actually use "this" anywhere in its source code (it was a smaller library, and a grep for "this" returned zero results). I suspect I'm just misinterpreting what was going on, but maybe not.

The "Q" package uses .apply() as part of some internal logic, which seems to mainly be used by publicly exposed functions such as promise.fapply(), promise.fcall(), and promise.fbind(). Ultimately the purpose is to mimic javascript's bind functions, but with some async logic added to them.

In the case of rxjs, they're exposing functions that accept a callback argument, and an optional this-value that will be applied to the supplied callback when it's called. This is mimicking built-in functions like Array.prototype.map(), which also accept both a callback and an optional "this" parameter.

Bluebird was using .call() for two different reasons. In the first scenario, they were wanting to define similar methods on two different classes. They did so by defining them all on one class, then creating a bunch of tiny, one-line methods on the other class that basically did FirstClass.prototype.call(specialThisValue, ...args). Basically, they were using .call() for code reuse purposes. In the second scenario, .call() is being used because they expose their own promise.bind() function, which accepts a "this" value, then applies that "this" to every callback in the promise chain. Part of the reason for this behavior is to allow the end user to keep state around between callbacks by mutating "this". See here for their rational behind this feature.

graceful-fs was simply a case of method extraction. They pulled off fs.read, and instead of binding it on the spot, they supplied the correct "this" value via .call() later on.

Ok, I think that's a good sample-size of many different possible use cases for bind functions. I'm going to go ahead and categorize these use cases, so that we can discuss the value a bind syntax provides to these general categories.

Irrelevant

• Readable-stream's use case is irrelevant to this proposal simply because it's not possible to add a new feature to improve the quality of transpiled code. By definition, transpiled code can't use new features.
• Yargs's use case is irrelevant because that code snippet can already be greatly improved by simply using the spread operator.

Customizing the "this" value of callbacks

Both bluebird's second example and the debug package use .call() to customize the "this" value of callbacks. In general, I think a good rule of thumb to follow is "prefer providing explicit parameters over custom, implicit 'this' parameters". In other words, it's generally better to just pass a context object to a callback instead of trying to conveniently set it's "this" value to this context object.

I'm not saying it's always bad to customize the "this" value of callbacks, I'm just saying we probably shouldn't encourage this kind of behavior, which means I would be against adding a bind syntax if this was the only use case for it.

protection from global mutations

This category wasn't found in any of the examples above, but it's still worth discussing. As shown in the README, node has a lot of code that uses .bind() type functions to protect against mutation of global properties. This is a fair point, and a valid use case for this proposal, but it can't be the only driving force. As discussed here, it seems this proposal can't feed off of "global mutation protection" alone, it needs stronger reasons to exist.

Mimicking existing language semantics

Both Q and rxjs mimic existing language semantics related to this-binding. Q provides .apply()/.call()/.bind() equivalents for promises and rxjs provides a parameter to set the "this" value of a callback.

These types of features are only useful if the end user finds it useful to bind custom this values to their callbacks, which is the type of thing we're trying to discuss right now. Perhaps, there's really not a big need for these features, and the API authors didn't really need to include them. But, then again, perhaps there are good use cases, so lets keep exploring.

Language workarounds

It seems a couple of the packages were using .call() simply because the language itself didn't provide what they needed in a direct way.

• kind-of simply needed to stringify an unknown object. This is currently not possible without .call().
• Bluebird was using .call() for code reuse purposes - they wanted to use the logic found within one method inside a method of a different class, so they did so by simply supplying using .call() with a custom "this" value. This particular solution seems to be pretty unidiomatic - if they ever switched to class syntax and private state, they would find that they couldn't keep using this code-reuse pattern. Perhaps there's better solutions to their problems that are more idiomatic that can be done in JavaScript today, or maybe in some future version of JavaScript after features have been added to help them in their use case.

For items that fall into this category, it's probably best to analyze each situation independently and figure out what really needs to be added to the language. Sure, a this-binding shorthand could provide some minor benefits to the readability of these workarounds, but what they really need is a way to do what they're trying to do without resorting to funky workarounds. We're already actively fixing a number of problems in this category, for example, there's the mixin proposal, and there's also the recently added Object.hasOwn() function which is basically a more direct way of doing Object.prototype.hasOwnProperty.call().

Method extraction

Both pretty-format and graceful-fs are basically doing a form a method extraction, except in both cases they're choosing to supply the "this" value at the call location instead of the extract location.

This proposal stated that it doesn't wish to focus on method extraction, but ironically, I think this use case might be the most important one among the ones that have been analyzed.

Others?

Looking at the above categories of use cases, it seems that many uses of .call()/.bind()/.apply() don't actually benefit much from a this-binding syntax, however, what's been presented is not an exhaustive list of possible use cases. So I want to pose the following question:

What specific uses of .call()/.bind()/.apply() does this proposal hope to help out with? Are there use cases beyond the ones listed above that this proposal seeks to make more user-friendly? If so, what are they? This might be a good thing to eventually document in the README as well. The README explains clearly that .call() gets used everywhere, but it doesn't dig deeper to find out why it's getting used all over the place - I think those underlying use cases are the real gold mine we're trying to hit. The uses of ".call()" seems to more-often-than-not be a symptom of a deeper problem that needs addressing.

Congratulations on stage 1! 🎉

First of all, I'm strongly supportive of the bind operator things, it is a very good supplementary to the language. Both this proposal and extension proposal has a very similar motivation and similar design, similar semantics on the :: operator. @hax mentioned that the parallel namespace is not an essential part of the extension proposal and can be removed under the temperature of the committee. And the significant difference between the two proposals is the semantics of binding accessors. I'm wondering if it is better for two proposals to collaborate and find a consensus?

2022-03 plenary bikeshedding slides

Possible criteria

Syntactic clarity

Would human readers often have difficulty with determining the syntax’s grouping?

Conciseness

Is the syntax significantly improve conciseness over the status quo?

Natural word order

Is the syntax’s word order more natural (e.g., subject.verb(object)) than the status quo?

Confusability with other JS features

Is there a risk of beginners and other developers confusing the syntax with regular dot property access?

Confusability with other languages

Is there a risk of developers confusing the syntax with visually similar syntaxes from other languages – especially if they have different semantics?

Overlap with other JavaScript features

Does the syntax greatly overlap with other features of the language?
(Note: A finding from the January post-plenary overflow meeting says, “In general, some overlap is okay, but too much is bad; we have to decide this on a case-by-case basis.”)

List of candidates

Receiver-first style (loose unbracketed)

This style was originally called “bind-this”, but we dropped function binding from it in 2022-03, so we renamed the style to “receiver first”.

rec :> fn(arg0)
rec ~> fn(arg0)
rec !> fn(arg0)
rec -> fn(arg0) 
rec #> fn(arg0)
rec ~~ fn(arg0)

Receiver-first style (tight bracketed)

This style was originally called “bind-this”, but we dropped function binding from it in 2022-03, so we renamed the style to “receiver first”.

rec:>fn(arg0)
rec~>fn(arg0)
rec->fn(arg0)
rec::fn(arg0)
rec:.fn(arg0)
rec-.fn(arg0)

Receiver-first style (bracketed)

rec~[fn](arg0)
rec![fn](arg0)
rec#[fn](arg0)

Function-first style

This style was originally called “call-this”, but we are now calling it “function first” to distinguish it from receiver-first call-this. See the original explainer by @tabatkins.

fn@.(rec, arg0)

This-argument style

First proposed by @rbuckton.

fn(this: rec, arg0)

Ok, I'm going to take another shot at playing with alternative proposal ideas.

This is an idea I've talked about briefly on a different thread. What if, instead of having a syntax shorthand for Function.bind(), we had a syntax shorthand for Function.call?

const { map } = Array.prototype

map@([2, 3], x => x + 1)
// This is the same as this:
map.call([2, 3], x => x + 1)
// And here's how you would do the equivalent with "->" syntax:
[2, 3]->map(x => x + 1)

(I wouldn't be surprised if "@()" creates some conflicts with the decorator proposal. The exact syntax can of course be figured out later)

Why do I like Function.call syntax more than Function.bind syntax?

• Personally, I find it hard to remember that the y in x->y is not a property on x, it's a local variable. This is a very big mental shift from how the "->" functions in a language like C++. (This probably isn't a huge deal - I'm sure I would get used to it fairly quickly, but it currently does make me pause for a moment every time I see it)
• Being required to use parentheses with the -> syntax is a little cumbersome when the function you wish to bind is found within an object. I think this is a good design choice for ->, but it's also unfortunate because this will likely be a common scenario. Compare Array.prototype.flat@([2, 3]) to [2, 3]->(Array.prototype.flat)()

Note that we're not losing any functionality by using a Function.call() syntax. Here's how we can use the call syntax for a bind-without-call use case.

const data = [2, 3]
const { map } = Array.prototype
const { bind } = Function.prototype

// Instead of this:
const myMap = data->map

// We can do this:
const myMap = bind@(map, data)

// Or just this:
const myMap = (...args) => map@(data, ...args)

I view this call syntax as only a marginal improvement over the current proposal, but it still seems like an improvement, at least until others come and expose all of its flaws :).

Method extraction (along with the calling of extracted methods) is a core use case of this proposal. For example, method extraction is essential for security from prototype pollution and other global mutation.

However, a non-goal of this proposal is what I currently call “tacit method extraction”: a (confusing) term I made up to refer to when a method is implicitly bound to its original owner, creating a bound function.

// “Explicit” method extraction results in a `this`-dependent ordinary function.
// This is handled by this proposal.
const { slice } = arr;
// The `this` value is supplied in the call.
arr::slice(...args);

// “Tacit” method extraction results in a `this`-independent bound function.
const slice = arr&.slice;
// The `this` value is not supplied in the call, because the function is bound.
slice(...args);

(Note that “tacit” method extraction is only useful on instance objects; it would not be useful on prototype objects, because calling a method on a prototype object is not very useful. In contrast, “explicit” method extraction is useful on prototype objects; the extracted prototype method could then be called on.)

// “Explicit” method extraction can extract from a prototype object…
const { slice } = Array.prototype;
// …and then a different `this` value may be supplied in the call.
arr::slice(...args);

I think these two concepts could use better names than “explicit” versus “tacit”. I don’t really have any other ideas, though.

(There’s even a third type of method extraction called “call-binding”, in which the this binding gets “uncurried” into a new (bound) function, using fn.call.bind, so that this is once again supplied at the call. @ljharb’s call-this call-bind library does this; Node’s primordials also use this pattern. I don’t even want to think about how they should fit in our nomenclature.)

babel is cool, but slow & I've seen many new projects skip Babel & use Vite or ESBuild, both of which run much faster, saving both time & energy.