[doc/ffi] More actively push `package:ffigen`?

[dcharkes]

Should we consider pushing FFIgen more actively?

FFIgen completely removes the need to write bindings by hand. This makes it much easier for users to (1) satisfy all the custom static checks, and (2) get the C types right, avoiding segfaults at runtime.

First, we could add a link package:ffigen from all analyzer/CFE error messages that give type mismatch errors in the FFI.
We do already mention FFIgen in https://dart.dev/interop/c-interop#generating-ffi-bindings-with-packageffigen, and error messages link to that documentation page. But the documentation is quite far down.

Secondly, we should maybe have a dart create ffi_package or something that has a setup with FFIgen from the get go.

Thoughts? @mraleph @mkustermann @mit-mit @liamappelbe @HosseinYousefi

[mkustermann]

For large API surfaces users are very likely to use package:ffigen anyways, because it's just way too much effort to write by hand for huge APIs.

So that leaves the starting use case for little bit of C code.

IMHO it would be nice to have a simple web app (e.g. dart.dev/ffigen) where one can paste some C code in and it spits out the bindings (it can have options to use declarative bindings or not, regexp to match things to generate bindings for, etc). Possibly it can also spit out the yaml file or procedureal use of package:ffigen.

If we make this web app embeddable our documentation could even have the embeddable view in there (similar to how we allow code snippets to be embedded in documentation)

=> Similar to godbolt.org but for C -> Dart bindings

[dcharkes]

I like that idea. Using dart server as backend and flutter web as frontend. It would be the perfect GSOC project.

[mkustermann]

I like that idea. Using dart server as backend and flutter web as frontend. It would be the perfect GSOC project.

It doesn't have to be a complicated server. It could even use stateless cloud functions. It could use/share infra structure with dartpad. /cc @devoncarew

[devoncarew]

I'd guess just mentioning ffigen in all the docs (dart:ffi, interop/c-interop, ...) would get us a lot of the way there. You'd want it above the fold and called out; i.e:

Note

If doing non-trivial amounts of interop, please consider using package:ffigen.

We could add a backend call for dartpad which could then be called by any trivial front-end client (a few lines of JS, ...). It would just be a RESTful POST. I'm not 100% of the value proposition of a website like this however - probably separate from the question about discovery.

[parlough]

In relation to documentation:

The work is a bit ill-defined currently but we're overhauling and adding various interop documentation on the website. I'll likely create an umbrella issue for the the various pieces that are being explored, but highlighting and better documenting ffigen can definitely be a part of that. I'll come back and update this comment to link there. Edit: dart-lang/site-www#5475

Do note that the Flutter website also needs more documentation in this area, including answering the common question that developers have of when to use ffigen vs pigeon.

\cc @craiglabenz @MaryaBelanger

[dcharkes]

@devoncarew I think the issue for new developers is that they are trying to call a single function through FFI, writing the bindings by hand, and getting the bindings wrong. @mkustermann suggestion could prevent getting it wrong by having a box on the website somewhere where you can paste in your C function and get the correct Dart FFI bindings.

[MaryaBelanger]

The work is a bit ill-defined currently but we're overhauling and adding various interop documentation on the website.

Still very ill-defined (and not updated between when Craig first wrote that doc and the most recent ffigen work landing), but that PR is here :) dart-lang/site-www#5269

[dcharkes]

"ffigenpad"

@jonasfj

[TheComputerM]

https://ffigenpad.surge.sh/ 👀