WebAssembly
`.wit`: default implementations
I'm proposing an addition to the current syntax to support default implementations for functions.
Sometimes a function isn't required to be implemented and its return could be substituted for a default value. This happens quite often and even more so with functions that don't have a return value. Imagine having to write dozens of functions that do absolutely nothing but are required exist.
In Rust, we extensively use default trait implementations to remove this type of boilerplate. For instance, the Iterator trait has 75 methods, 74 of which have default implementations. I'm not suggesting we allow behavior in wit definitions. Instead, we need a way to define default return values, like in size_hint that returns (0, None) by default.
Structured Annotations could be a good candidate for this syntax. We probably don't want to use curly brackets at the end of the function, as that would normally imply behavior.
Good point and interesting idea! I've had a similar experiences where default implements are super-useful like you're describing.
Because we roundtrip Wit through the component model's binary format and because default function implementations don't belong in the type signature (iiuc, they are information that only producer toolchains consume as an implementation detail of how they produce components that implements the containing interface), this does seem like information that belongs in a custom section of a binary Wit document. Structured Annotations could be used to do this, but their use case is one level more general than this, since they are meant to express arbitrary annotations for an open-ended set of producer+consumer pairs. Instead, for this use case, it might be better to define built-in syntax to Wit as this could enable better developer ergonomics in a couple of different ways.
In any case, it will be a challenge to determine the scope of what can go in default function bodies; constants are a good start, but as soon as you have that, you'll immediately want, e.g., the ability for a default function to call another function in the same interface (fixing one argument or rearranging arguments) and the ability to define "macro" functions that are default-implemented in terms of multiple more-primitive interface functions. (If you give a mouse a cookie...) So then this starts to look like a small expression language. One way to not invent a new ad hoc expression language would be to reuse the post-MVP custom adapter functions, which seem ideally suited to this task (adapting). Unfortunately those are post-MVP, so I'm wondering if this feature is too.
