Find a way to add new fields to requests, responses, events, ... without breaking backwards compatibility about ruma HOT 13 CLOSED

I have bad news, I'm surprised this didn't work.

---- src/room/create.rs - room::create::CreateEventContent::new (line 52) stdout ----
error[E0639]: cannot create non-exhaustive struct using struct expression
  --> src/room/create.rs:59:14
   |
10 |   let create = CreateEventContent {
   |  ______________^
11 | |     ..CreateEventContent::new(creator, true, version)
12 | | };
   | |_^

Would a constructor for the required fields and "builder" methods for the optional fields be the next best thing?

from ruma.

Damn it, needs to be done using mutation then 🙄

from ruma.

The first commit to make some of our structs #[non_exhaustive] is in master since yesterday: f9639e1.

from ruma.

Damn it, needs to be done using mutation then 🙄

Throwing random idea to (perceptively) reduce mutation:
What about declarative macro_rules only for Request object that expands to mutations? Will it be easier to consume?

let request = construct_request!(Request::default(), {
  to: String::new("somestring"),
  dir: Direction::Forward,
});

// which expands to

let request = {
  let item = Request::new();
  to: String::new("somestring");
  dir: Direction::Forward;
  item
};

Edit: remove "actually" because after re-reading it, I think I sounded annoying :D

from ruma.

@Kelerchian I thought I had mentioned that possibility here before, but apparently not! Maybe I did in the Matrix room, but whatever. The main reason I haven't done this yet is that there's no obvious syntax for such a macro. The one I came up previously was something like

let req = whatever!(Type::constructor(a, b) =>
    .c = uint(1),
    .d = "foo".into(),
);

but I like yours much more (you should fix the expanded form from let to let mut and : to = though 😛)! It should have a more general name than construct_request, but I'd be happy to have this added to ruma-common :)

Maybe we should also look into prior art, as I'm pretty sure other people have discussed this in the context of Rust, and IIRC I've heard of a language where this is a built-in feature.

from ruma.

The discussion about consuming non_exhaustive struct is here
Here's the related rfc page

The journey is still long it seems. And knowing there's no official way to do this in ruma crate, it might be just better to tell user to mutate and use helper if necessary.

I wrote a crate you can use here https://github.com/Kelerchian/assign
This is not published yet to crates.io because I don't want to publish anything not used by anyone,
notify me to publish this if you feel this is usable or copy paste / modify as you see fit and put in ruma-common.

Also I didn't follow your syntax recommendation because I'm not sure what => is supposed to mean in rust.

from ruma.

Also I didn't follow your syntax recommendation because I'm not sure what => is supposed to mean in rust.

It was not a recommendation, as I said above I like your version much better.

I will think about naming a bit more (not a huge fan of assign! right now) and decide how to proceed based on that.

Thanks a lot for helping with this! :)

from ruma.

You're welcome.
I was searching for an unused name in https://docs.rs/ and then assign crossed my mind. JavaScript devs should be familiar with it.

from ruma.

Hm, that does make some sense. I will look into your new crate in more detail and probably send one or two PRs, but encourage you to release the first version now, to make sure you get the name on crates.io :)

Would you also be willing to give me / everyone with ownership of the ruma crates on crates.io (github:ruma:maintainers) co-ownership of the crate?

from ruma.

I'm not comfortable with the crates.io owner system.

I'll add you as collaborator in the meantime.
The CI/CD is in place,
it'll build and test on pull requests
build, test, and publish on merge on master branch

from ruma.

I might be adding you guys as crate co-owners sometime soon

from ruma.

Hey @jplatte I know I have been advertising a tool for making a mutation looks like a declaration, but how about builder pattern?
Like this https://github.com/stiiifff/did-common-rust/blob/master/README.md

from ruma.

@Kelerchian That is what I was originally going for, however it means either writing or generating much much more code (which then results in longer compile times) and doesn't have any clear upsides for our use case.

from ruma.