yaoyaoding commented on PR #229: URL: https://github.com/apache/tvm-ffi/pull/229#issuecomment-3498558436
I asked Gemini to summarize the two design choices: | Option | Pros ✅ | Cons ❌ | | :--- | :--- | :--- | | **1. Support All Signatures** (`T`, `const T`, `T&`, `const T&`, `T&&`, `const T&&`) | **Increased compatibility** and ease of use with existing native C++ interfaces. Provides **full C++ idiomatic support** for exported functions. | **Increased template complexity**, potentially slowing down compilation. **References (`T&`, `T&&`) are semantically misleading** because the FFI input is converted to a value first (no actual object to reference/move from). | | **2. Limit Support** (`T`, `const T&`) | **Optimizes compilation speed** by reducing template complexity. Enforces **idiomatic FFI practice**, where input is a value or a read-only reference. Nonsensical signatures (`T&`, `T&&`) can be **explicitly disabled with clear errors**. | **Breaks compatibility** with native C++ interfaces using other signatures. May require more user adaptation/rewriting of existing C++ functions. | I prefer the Option 2 that only support (`T` and `const T&`, and with more user-friendly error message for unsupported modifiers, as @DarkSharpness suggested): 1. Since we introduce new types like `ffi::TensorView`, etc for tensor passing. It's likely that the users need to write the TVM-FFI interface functions, instead of reusing existing functions. Thus, the advantage of option 1 is applicable to limited cases. 2. It's a little confusion when using other modifiers because we first convert the arguments to intermediate values and then pass these intermediate values to the user's function. We can not actually own or modify the user provided argument with the original c++ semantics. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
