Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet: support mutable references to primitive and primitive-like (enums) types #134

Open
CBenoit opened this issue Feb 2, 2022 · 3 comments
Labels
B-dotnet Dotnet backend enhancement New feature or request

Comments

@CBenoit
Copy link
Contributor

CBenoit commented Feb 2, 2022

The out parameter modifier can be used to support that.

❗ Currently backend is just generating incorrect code (fortunately, it doesn't compile).

This would be nice to support alternate functions that does not throw exceptions when performance matters.
For instance, Int32.Parse has a non-throwing counter part called Int32.TryParse.

struct Foo;

impl Foo {
  // C# wrapper will throw an exception on error
  pub fn parse(s: &str) -> Result<u32> {}

  // In this version, an error code is returned instead
  #[diplomat_attr(not(dotnet), ignore)] // Useful only for backends relying on exceptions for errors
  pub fn try_parse(s: &str, result: &mut u32) -> bool {
    match Self::parse(s) {
      Ok(v) => {
        *result = v;
        true;
      }
      Err(_) => false,
    }
  }
}
@Manishearth
Copy link
Contributor

I wonder if any of the backends handles this well: because on many of them you need conversion before mutation, and I'm wondering if it just makes more sense to ask people to write the APIs as taking in the primitive and spitting out a new one. (Perhaps expand the restriction on non-opaque structs to be that references can only contain opaque types/strings/slices, no primitives, and no mutation on strings/slices). Unsure though.

@CBenoit
Copy link
Contributor Author

CBenoit commented Feb 2, 2022

I'm wondering if it just makes more sense to ask people to write the APIs as taking in the primitive and spitting out a new one.

If we do that we can't support the use case mentioned above anymore, but it's not necessarily a big deal because it's always possible to manually extend generated C# classes with new functions and then provide a non-throwing version of Parse for instance. I would prefer to not write that manually, but not a blocker.

no mutation on strings/slices

However that restriction would be a bit problematic for me, because as mentioned in #126, I have a use case largely depending on allowing this.

@Manishearth
Copy link
Contributor

Yeah perhaps we should be lax about this, the main fear I have is that in some cases this requires a copy. If we can make this work with the JS backend I think it would be great.

@Manishearth Manishearth added B-dotnet Dotnet backend enhancement New feature or request labels Feb 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-dotnet Dotnet backend enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants