Jim Teichgräber (May 06 2026 at 13:41): Jim Teichgräber (May 06 2026 at 13:41):The wit reference says:
As shown in the
blobexample, a resource can contain:
[...]
* at most one constructor: a function that is syntactic sugar for a function returning a handle of the containing resource type. The constructor is declared withconstructor.
(this is also mirrored by what WIT.md says about constructors)
This seems to be misaligned with what wit-bindgen backends do, in particular, the "syntactic sugar" part. In my understanding, that should mean that it should be possible to define a constructor, without using the sugar, i.e., just by defining "a function returning a handle of the containing resource type". I've tried this across many backends, and none of them seem to handle it that way, language-level constructors are only generated from constructor-keyword methods. Same with exported "[constructor]..." names. Any function returning a handle of the containing resource type just becomes a normal "[method]...".
Is this expected? Is this part of the spec outdated, or not to be taken quite literally?
Does it stem from the related idea that any method in a resource is mostly syntactic sugar, as it could just as well be an interface function taking an implicit self parameter?
I'm wondering how we should handle this case in our Kotlin bindings generator. Right now I'm leaning towards simply emulating the behavior (special-casing constructors) of the other wit-bindgen backends that I can see :slight_smile:.
Thanks!
Alex Crichton (May 06 2026 at 14:23):The spec here is more a set of guidelines for bindings generators and there's not really a strict speciifcation of what bindings generators are supposed to do. Each language can take its own direction in whatever way suits it best, and the goal is that WIT accomodates such possibilities with rules such as disallowing [constructor] and [static]foo.new (a "new" method) since languages without constructors, like Rust, don't have a keyword
Alex Crichton (May 06 2026 at 14:24):In that sense I think it's totally fine for Kotlin to special-case this, even if other languages don't. If it works out then other languages that have constructor support should likely follow-suit
Jim Teichgräber (May 06 2026 at 15:40):Thanks for the quick answer!
In that sense I think it's totally fine for Kotlin to special-case this, even if other languages don't. If it works out then other languages that have constructor support should likely follow-suit
My thought was more to align with what other languages do right now (also ones without language level constructor support), which is what I would call special casing constructors on the constructor keyword. But mabe I have a misunderstanding here?
Alex Crichton (May 06 2026 at 17:01):Oh yeah that's definitely reasonable, special-casing constructor, but I thought you were raising this issue where functions-returning-own<self> aren't special-cased when the wit reference says they could?
Till Schneidereit (May 06 2026 at 18:16):for some background, we introduced the constructor keyword (and the [constructor]foo exports in component interfaces) to enable bindings generators to generate real constructors for languages that support them without having to resort to heuristics. The "syntactic sugar" here refers to the fact that on the Component Model level you can't express anything with [constructor]foo that you can't also express with [static]foo.something. The former additionally provides strong guidance to bindings generators, though.
None of that means though that a bindings generator can't also decide to treat other exports as constructors in the bindings if their signatures make that workable for the given language.
Last updated: Jun 01 2026 at 09:49 UTC