Possible solution: Make it a function

[Jack-Works]

Make debugger a valid identifier (but no allowing re-defining or shadowing) and always point to x => (__engine_internal_print__(x), x)

Possible usage:

await x.then(debugger)
arr.map(debugger).forEach(...)

[ljharb]

that seems like it'd add a stack frame unless engines were very careful?

[Jack-Works]

Idea from Ron Buckton: Consider debugger.x meta-properties for extensions

Cool, that might enable more different debug behaviors.

For example, debugger.pause(pause when called), debugger.pauseIf(condition), etc...

[devsnek]

@rbuckton's idea is definitely growing on me. having separate debugger.break(v) and debugger.log(v) could also solve @syg's separation concern. We probably want to restrict them to being a direct call syntax, much like import(), to signify the importance of the invocation location (especially for break).

[schmod]

Couldn't the same thing be achieved with a logging library that invokes a callback?

lazyLogger.debug(() => `The result is: ${expensiveOperation()`));

This is more or less the approach that log4j adopted when Java 8 added support for lambda functions.

---

Admittedly, the callback format won't mesh well with the existing Console object (which is, notably, not a part of ECMA-262), as it would simply log the function.

I wonder if we could generalize this proposal, and provide some syntactic sugar to wrap expensive values in a callback, ie:

⏰expensiveOperation(); 
// compiles to the equivalent of:
() => expensiveOperation();

// which you could use like:
console.debug(⏰expensiveOperation());

// a logging library could then infer that arguments passed this way 
// should be evaluated and logged (if the logger is active)

// pseudo-code
class Console {
   debug(message) {
      if (!this.shouldLog('debug')) return;
      if (message instanceof Supplier) print(message());
      else print(message);
  } 
}

In this case, the transpilation process is intuitive, we'd have opportunities to integrate it into existing logging libraries/frameworks without changing their contracts, and we wouldn't be limited to logging as the only use-case.

This shorthand could also shave a few characters off some common JSX use-cases:

<div onClick={⏰doStuff(someVal)} />

(NB: The ⏰ emoji is a deliberately-ridiculous strawman to postpone any arguments about the what operator we should use)

[Alexsey]

Actually, there is already a function tap in lodash. For this specific perpose I would even recommend tap from lodash/fp:

function doSomething(a) {
  let b = (a + costlyOperation()) * 2;
  // ...
}

foo()
  .then((bar) => bar.baz());

are becoming

const { tap } = require('lodash/fp');

function doSomething(a) {
  let b = tap(console.log, (a + costlyOperation()) * 2);
  // ...
}

foo()
  .then((bar) => tap(console.log, bar.baz()));

Or, considering the fact that tap in lodash/fp is curried, even

foo()
  .then((bar) => bar.baz())
  .then(tap(console.log)); // looks better and would log already resolved value in case if bar.baz() returns a Promise

And also can be used to unobtrusively investigate methods chains like

const res = arr
  .map((v, i) => v * 2 + i)
  .filter(v => v % 2);

this way:

const res = arr
  .map((v, i) => v * 2 + i)
  .map(tap(console.log)) // would log separately 2, 5 and 8
  .filter(v => v % 2);

Also, would look just great with pipeline operator:

const { tap } = require('lodash/fp');

function doSomething(a) {
  let b = (a + costlyOperation()) * 2) |> tap(console.log);
  // ...
}

foo()
  .then((bar) => bar.baz() |> tap(console.log));

Requiring no code change, only single place extention (modern IDE tools would allow doing such code modifications in 3-4 keypress)

[bmeck]

@schmod we actually looked at implementing that in Node a little while back, but ended up with a property .enabled instead, the performance was better by a little bit and it avoided some scoping nits from the added closure. nodejs/node#33424 had some notes on design here.