Adding ADR on UniffiTag handling #1932
Conversation
bendk
requested review from
skhamis,
jplatte and
mhammond
and removed request for
a team
|
|
||
| - Good, because it's more explicit. | ||
| - Good, because it's easier to explain. | ||
| Telling users "you always have to add `uniffi::use_*!`" to use a type from another crate is easier than saying you sometimes you need it and sometimes you don't. |
There was a problem hiding this comment.
This factor seems the most important to me. I don't want to have to go into the details about the orphan rule, remote types, etc. in order to explain to users if they need uniffi::use_record! or not.
bendk
force-pushed
the
adr-uniffi-tagging
branch
from
8f616b3 to
6d02cd1
Compare
|
Pushed an edit to this that:
|
|
I still think that Option 1 would be extremely annoying for larger projects consisting of multiple crates that don't need much or any bindings of independent external libraries. Option 3 actually seems very interesting to me but involves a lot of extra work for reducing the boilerplate so I don't know how realistic it is short-term. If somebody wants to look more into boilerplate reduction for that option, I think Overall, especially because I don't have that much time to put into this, I (still) strongly prefer option 2. |
bendk
force-pushed
the
adr-uniffi-tagging
branch
from
4b07693 to
1f7030e
Compare
|
We iterated around this and @bendk ended up landing our current "remote types" system, which I think we are all quite happy with! |
We've discussed this is various issues, most recently #1865. I think it's time that we have an ADR and discuss the question directly and by itself.
There's a lot more complex cases, for example structs/enums that contain fields with types from another crate. I don't think that affects the decision, but please tell me if I'm missing anything here.