From a86e9496623f9bbee77fb7b3b23e960ee47ebdc2 Mon Sep 17 00:00:00 2001 From: Mark Hammond Date: Wed, 5 Jan 2022 17:36:31 +1100 Subject: [PATCH] review comments from ben --- docs/diplomat-and-macros.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/docs/diplomat-and-macros.md b/docs/diplomat-and-macros.md index 3da99b5719..b563571743 100644 --- a/docs/diplomat-and-macros.md +++ b/docs/diplomat-and-macros.md @@ -118,9 +118,14 @@ pub struct MyFFIType { } ``` -Might be enough for the generation of the Rust scaffolding. However, the problems are in the -foreign bindings, because, eg, those foreign bindings do not know the names and types of the -struct elements. +Might be enough for the generation of the Rust scaffolding - in UniFFI's case, all we really need +is an implementation of `uniffi::RustBufferViaFfi` which is easy to derive, and UniFFI can +generate code which assumes that exists, much like it does now. +However, the problems are in the foreign bindings, because, eg, those foreign bindings do not know +the names and types of the struct elements without re-parsing every bit of Rust code with those +annotations. As discussed below, re-parsing this code might be an option if we help Uniffi to +find it, but asking UniFFI to parse this and all dependent crates to auto-discover them +probably is not going to be viable. ### Why is this considered a limition for UniFFI but not diplomat? @@ -236,6 +241,9 @@ So while we haven't exactly reduced the duplication, we have removed the UDL. We probably also haven't helped with documentation, because the natural location for the documentation of `MyFFIType` is probably at the *actual* implementation. +While it might not solve all our problems, it is worthy of serious consideration - fewer problems +is still a worthwhile goal, and needing a UDL file and parser seems like one worth removing. + ## Try and share some definitions with diplomat We note above that the type universe described by diplomat is somewhat "leaner" than that