Enhancing TypeScript’s String Operation Support for Class Instances with toString()

[mechamobau]

🔍 Search Terms

“TypeScript toString conversion”, “class instance string concatenation”, “automatic toString TypeScript”, “TypeScript dynamic string operations”, “custom toString method TypeScript”, “TypeScript class instance to string”, “implicit toString call TypeScript”

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I propose TypeScript to implicitly use the toString method on class instances in string contexts, improving intuitiveness and reducing the need for explicit conversions, aligning with JavaScript’s runtime behavior.

📃 Motivating Example

Imagine seamlessly integrating class instances into your string operations without a hitch. With this proposed feature, you no longer need to manually invoke toString() on your custom class instances when concatenating with strings or setting attributes. For instance, setting a canvas width directly with a Pixel object like canvas.setAttribute('width', Pixel.from(resolution.width)) becomes effortlessly intuitive. This enhancement not only streamlines your code, making it cleaner and less verbose but also bridges the gap between TypeScript’s static type checking and JavaScript’s dynamic nature, offering a more powerful and developer-friendly experience.

class Pixel {
  private _value: number;

  constructor(value: number) {
    this._value = value;
  }

  toString(): string {
    return `${this._value}px`;
  }

  static from(value: number): Pixel {
    return new Pixel(value);
  }
}

// With the new feature:
const resolution = { width: 800 };
const canvas = document.createElement('canvas');

// Directly use a Pixel instance in a string context
canvas.setAttribute('width', Pixel.from(resolution.width));

console.log(canvas.getAttribute('width')); // Outputs: "800px" without needing explicit toString() call

💻 Use Cases

1. What do you want to use this for?
   To simplify string operations with class instances, making code cleaner and more intuitive and helping with type assertions in string contexts.

2. What shortcomings exist with current approaches?
   The need for explicit toString calls or manual conversions, leading to verbose and cumbersome code.

3. What workarounds are you using in the meantime?
   Manually invoking toString on class instances or using additional functions to handle conversion.

[fatcerberus]

Most of the reason TypeScript even exists in the first place is because implicit conversions in JS are error-prone in a thousand different ways, so it’s basically intentional that you have to do explicit conversions.

In this case specifically: every object inherits a (useless) .toString() through Object.prototype so this would definitely open the floodgates to the exact kind of bugs TS is designed to prevent.

This might provide further insight:
https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

[fatcerberus]

On a further note: In general, just because a function accepts a string parameter is no guarantee that it’s okay with receiving arbitrary toString-able objects.

[MartinJohns]

Duplicate of #35945.

[RyanCavanaugh]

There's just not enough information about intent to really know which implicit coercions are OK and which aren't. On the provider side, [object Object] is a running joke about JS for good reason - just because something has a toString method doesn't mean it's a useful thing to call. On the receiver side, a decent number of things that say they take a string will get by with an implicit toString call, but not everything, and it's rarely documented what the true constraint is.

[typescript-bot]

This issue has been marked as "Declined" and has seen no recent activity. It has been automatically closed for house-keeping purposes.