Why does typescript seem "unhelpful" when it comes to `toString()`?

[mental geyser]

bawdyinkslinger#0

Playground Link

Preview:```ts
type ToString = {toString: () => string}
type Foo = {bar: string}

function a(): Foo & ToString {
return {bar: "a", toString: () => "a"}
}

function b(): Foo & ToString {
return {bar: "b"}
}

function c(): Foo {
return {bar: "c", toString: () => "c"}
...```

You can choose specific lines to embed by selecting them before copying the link.

[astral canopy]

!ts

[mental geyser]

type ToString = { toString: () => string };
type Foo = { bar: string };

function a(): Foo & ToString {
  return { bar: "a", toString: () => "a" };
}

function b(): Foo & ToString {
  return { bar: "b" };
}

function c(): Foo {
  return { bar: "c", toString: () => "c" };
//                   ^^^^^^^^
// Object literal may only specify known properties, and 'toString' does not exist in type 'Foo'.
}

[astral canopy]

I'm not understanding how this helps me:

a is fine. That makes sense to me.
b is okay-ish. Since I'm explicitly stating the return should have a toString, I wish it enforced I implement it, but I understand that every object comes with a default implementation.
c on the other hand just seems annoying: b established that typescript understands object literals have a default toString. Why do I have to explicitly put it on a type if it's not going to enforce I implement it anyway?

Can someone explain why this works this way? It seems unhelpful.

[raven thistle]

Seems like a reasonable default, if you want to override toString you need to do so explicitly

[wintry lichen]

excess properties are usually a mistake

so there's specifically extra typechecking for excess properties, and only excess properties

[astral canopy]

yeah I even get the value in that. But specifically for methods on every object with a default impl, how is this useful?

[wintry lichen]

there's a large difference between a default impl, and a custom impl

not that anyone is supposed to rely on that

but also, that doesn't mean that people don't rely on it

[astral canopy]

Sorry, I keep reading these last three lines, but I don't understand what they mean

[astral canopy]

Maybe you could word them differently? I'm still wondering about this ^

[analog hearth]

In theory, maybe TS could special-case toString, as it's something that can still be "used" even if it's not explicitly included in the type.

In practice, it's probably not common enough to be worthwhile?

If people are overriding toString it's way more common to do that with a class, and not include it on object literals

[astral canopy]

ah, I see

Why though? It sounds like I'm not writing idiomatic code

[analog hearth]

Yeah, I don't have any sort of empirical basis, but I just don't see a ton of toString implementations in JS/TS at all: most structures in JS boil down to JSON which is already pretty easily loggable, and the dev tools are pretty good for expanding/collapsing objects.

I think that style of adding toString implementations is more common in OOP-heavy style coding, which is probably why I associate it more with classes than raw JS objects.

[astral canopy]

yeah I have a Java background

Okay thanks, @analog hearth and everyone