You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned here, different languages may have different variant arguments, so different languages are split out and run as main commands separately, which is a big step forward.
We can go a step further. In addition to providing a separate language as the main command entry, I also hope that the language here can exist in the form of a subcommand, so that all functions can be completed with one binary, and variant arguments related to the language itself can be used:
I think we are more likely to head in a different direction, and have each binding be 100% responsible for generating bindings for a given language. This would make things more consistent with external bindings, such as golang or c#. Each language gets it own binding binary.
To put it another way, I think we should stop treating the builtin language as "special".
If I understand correctly, in the future there may only be uniffi-bindgen-{LANGUAGE}, but no uniffi-bindgen generate --language {LANGUAGE}, nor uniffi-bindgen generate {LANGUAGE} mentioned by this feature.
In that case, further, the current uniffi-bindgen generate subcommand will also be removed in the future.
Yeah, that's correct. Although I guess you could imagine a world where bindings were like git - eg, uniffi-bindgen generate {LANGUAGE} was generic and just tried to execute uniffi-bindgen-language or similar.
IOW, I think we mainly just want for none of the languages to be "special" - so "swift" and "go" and "js" etc all work as well as each other.
Currently, the following commands are used to generate language-specific bindings:
As mentioned here, different languages may have different variant arguments, so different languages are split out and run as main commands separately, which is a big step forward.
We can go a step further. In addition to providing a separate language as the main command entry, I also hope that the language here can exist in the form of a subcommand, so that all functions can be completed with one binary, and variant arguments related to the language itself can be used:
Is such a feature request acceptable, or is it the goal of the project to accept such a change?
The text was updated successfully, but these errors were encountered: