Consider renaming error resource `to-debug-string` to `to-string`

[guybedford]

I've found that if I have a resource with a to-string that coerces to toString in JavaScript and immediately supports logging correctly etc due to JavaScript's blessed handling of the toString() method.

If the goal was to avoid this kind of conflation due to conflicts, I just wanted to mention that in general using the to-string name actually does what we do want in this error resource case for JavaScript, so could be worth considering aligning on. So far as other ecosystems don't have reasons to inhibit its use, JavaScript is certainly not a blocker and in fact if anything a reason to use to-string.

[pchickey]

Just to give some context, an important consideration of the name to-debug-string is to communicate to the user that this information should just be for debugging purposes. It is not stable across implementations, or even in the same implementation, and we hoped that containing debug would make it clear to not use this method for control flow based on matching the string.

[guybedford]

Right, in JS, new Error('blah').toString() will give the string: "Error: blah" which is the same kind of debug string I think, while console.error(new Error()) will give the full structured debug log stack. And typically err.code etc are used for handling error cases. So I think there is alignment on meaning for the most part.

[pchickey]

Thanks, I didn't have enough JS context to understand that.

It is troublesome to select names so that generated code works idiomatically in a given guest or host language or ecosystem. These definitions have to work in any language that can target WebAssembly. If we had to consider each target language idiom, that would put a huge burden on interface authors (e.g. in this case, I don't know JS idioms, should I be expected to learn them to author wits?) and we will always end up disappointing some language or another where they inevitably conflict.

Instead, I think the best way to remedy this is for each language's bindgen tools to be configurable (or otherwise clever enough) to rename a given wit name to whatever name is idiomatic for that language. In this case, it seems reasonable for JS guest and host bindgens to map each use of the wasi:io/stream.error.to-debug-string method to use the JS identifier toString. This reflects the stance the Component Model has made with identifiers: we don't expect that kebab-name is a valid identifier in the vast majority of target languages - part of why I like that format is because it obviously is not a valid identifier in many popular languages - and instead bindgen is responsible for changing it to be KebabName or kebab_name or whatever is appropriate in a given context and target language. Same idea with wit identifiers not excluding any language's keywords as well.

[guybedford]

Saying we are open to embedding-specific mappings for error resources would definitely be interesting to explore here. I wonder if it would even make sense to consider mapping the error types to subclasses of real JS errors.

[lukewagner]

The discussions around the design of wasi:io errors and the various design goals (extending error types with domain-specific error information, supporting externally-configurable logging integration) left me thinking that, post-Preview-2, it might make sense to add an error type to the C-M (so, e.g., you could return a result<_, error> without importing anything). This would both allow error to do smart efficient things at the Canonical ABI level and also be more composable (allowing any interface to define its own additional error info (via func(e: error) -> my-extra-info) without forcing all the implementations to funnel through a single implementation (quite symmetric to the situation with pollable). And my point in bringing this up is that, if we were to add an error type (again, in the Preview 3 timeframe), then result<T, error> would I think have a natural mapping to and from JS Error exceptions.