Expose pub fn of a re-exported struct to Dart

[patmuk]

Describe the bug

I noticed that functions of re-exported types are not generated for accessing in Dart.

As in Rust these are available it would be nice to have the same behavior for Dart access.

For example, if I have: file myStruct.rs

pub struct MyStruct{
   field: String
}

impl MyStruct{
   pub fn get_content(&self) -> String {
       self.field
   }
}

and another file myApi.rs

pub use domain::MyStruct;

pub fn useMyStruct(myStruct: MyStruct){
   myStruct;
}

and configured flutter_rust_bridge.yaml with

rust_input: 'crate::application::api'

then the function myStruct.get_content() is not generated in FRB.

An easy workaround is to add to flutter_rust_bridge.yaml myStruct.rs

rust_input: 'crate::myApi, crate::myStruct'

but since other rust code would be able to access the function through a re-import (by use other_project::myApi) it would be nice to have Dart be able doing the same.

Would that be easy to implement - or have unwanted side effects and was thus disabled intentionally?

Steps to reproduce

Implement the above example ... I can do that if needed.

Logs

Nothing specific written into the logs.

Expected behavior

No response

Generated binding code

No response

OS

No response

Version of flutter_rust_bridge_codegen

2.5.0.

Flutter info

No response

Version of clang++

No response

Additional context

No response

[fzyzcjy]

Good suggestion!

have unwanted side effects

It seems that frb chooses to scan functions inside rust_input and ignore functions/methods outside that. Therefore, by doing this re-export, it may be a breaking change...

In addition, we use pub use to allow users to expose third party types to be understood by frb_generated.rs, thus giving pub use a second meaning may be a little bit confusing.

[patmuk]

Good suggestion!

Thanks :)

have unwanted side effects

(...) doing this re-export, it may be a breaking change...

Hmmm ... I think this might not break old code: more functions would be exposed, but they would not be used (if I don't overlook something). Surely on the rust side nothing changes, on the dart side there should be just more functions accessible but not automatically called.

Maybe there would be a conflict if a struct is re-exported and part of rust input - potentially duplicated code. But we might be able to detect this and warn when generating code.

In addition, we use pub use to allow users to expose third party types to be understood by frb_generated.rs, thus giving pub use a second meaning may be a little bit confusing.

Oh, yes, that is a good point. The question is then is a user would or would not like to have the functions of these types exported as well. I would assume that I might want this functions - if I deal with a specific struct, these functions would give me tools do deal with it. But maybe I am thinking to object-oriented about that. In reality I would probably not have a need for 3rd party structs in Dart and deal with them in rust ...

Maybe I misunderstood you - but isn't the scenario nearly the same? pub use to export structs of own, not rust input included structs and for 3rd party structs? In both cases currently without functions?

[fzyzcjy]

Looks reasonable! I will think about this proposal a bit later.

[patmuk]

Sure, take your time! There is a very easy workaround, so this is more of a "clean-up" :) Worth doing only is easy todo and side-effect free :) Though a bit too much working with the inner core that I feel comfortable doing.

[fzyzcjy]

I think this might not break old code

I was thinking about if the newly scanned function has something that frb does not understand. But yes, most of the time frb will happily skip functions it does not understand, so it should be OK.

Maybe there would be a conflict if a struct is re-exported and part of rust input

Yes that also look like a problem.

Maybe I misunderstood you - but isn't the scenario nearly the same? pub use to export structs of own, not rust input included structs and for 3rd party structs? In both cases currently without functions?

The problem is, pub use currently has semantics that "that type is exposed s.t. frb_generated.rs can use it"; but we are now introducing a second semantics that "that type is exposed to the Dart side". That's why I say it can be confusing...

[patmuk]

I think this might not break old code

I was thinking about if the newly scanned function has something that frb does not understand. But yes, most of the time frb will happily skip functions it does not understand, so it should be OK.

Maybe there would be a conflict if a struct is re-exported and part of rust input

Yes that also look like a problem.

Yes - it sounds like this could happen - but I assume that the chance is very low. And probably the fix very easy: If we have, for example, a name clash, the formally good build would break, but a good error message would make it trivial to fix.

Maybe I misunderstood you - but isn't the scenario nearly the same? pub use to export structs of own, not rust input included structs and for 3rd party structs? In both cases currently without functions?

The problem is, pub use currently has semantics that "that type is exposed s.t. frb_generated.rs can use it"; but we are now introducing a second semantics that "that type is exposed to the Dart side". That's why I say it can be confusing...

Aha. Currently the type is exposed to Dart as well, not only to frb_generated.rs - but yes, it is the difference between „use a rust structure“ vs „use a function“.

Maybe my use case can show why it would be good to expose functions as well - however, it is not a big deal to not do that:

I have a api-class which offers a „process_command“ function. Here I modify data structures, which are passed around, but are not used in Dart directly. This data structures (domain objects) have inner fields, which I don’t want to expose - so I use ‚pub use‘ for exposing the main structures only.

Now I want to display some attributes in Dart. For that I implemented a function which computes a String that is moved to Dart. However, this function is coded in the domain file, as coming from OOP I want to have it close to the type definition. Now I actually implemented it in the api file, which ‚pub use‘es the main struct and ‚use‘es the inner fields to implement that String producing function.

The „workaround“ is so easy and not necessary wrong, that it is ok as well. I was just wondering, if it wouldn’t be less confusing if ‚pub use“ behaves the same to rust and dart code.

[fzyzcjy]

Hmm I see. I personally am still not sure whether we should add it; but if you have the interest in doing so, feel free to PR!

[patmuk]

I had an unexpected twist, which is a good argument against implementing this!

I implemented some generic traits, using associated types and implies, etc. These constructs are not supported by FRB at the moment, so the generated code was faulty.

Thus, I actually removed my "domain::*" code from rust_inputs, so that only the types are scanned, not the functions. These are accessed through proxy functions in my API (wich do a bit more).

So, taking into account that more syntactical constructs could be added in future, to avoid FRB having to implement those all, I thing we should not implement this issue!

[fzyzcjy]

That looks like also a good reason!

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.