Thomas Eizinger

> Ah, note that `Future` is a re-export from `core`, and #77 already implemented that with a unified `Output`. I'm not sure why I did that -- probably just because...

FWIW, a not unified output would have been more powerful because you can always call `into_inner` if they end up being the same type. Not sure if you ever plan...

> > FWIW, a not unified output would have been more powerful because you can always call `into_inner` if they end up being the same type. > > It's not...

> Oh, calling `into_inner` on the output, _after_ polling/`await` -- yes that would work. Would you like me to re-word this issue for changing the `Future` implementation (in a potential...

> Sure, it wouldn't hurt to have a clean summary of proposed changes. Done!

> This is a couple of versions behind, and there have been some recent updates to ProtonDrive (and its dependencies). Could you retry this with [`v1.65.1`](https://github.com/rclone/rclone/releases/tag/v1.65.1) and report back if...

> > but that can be solved by adding `is_` getters. > > How are these different to a non-opaque struct with a `non_exhaustive`? Removing them would still be a...

It might be a bit hacky but you can make a newtype that implements `Deref` and `DerefMut`. Within the `DerefMut` implementation, you can set a `dirty` flag and essentially track,...

I am also in favor of the last proposal. In addition to the constant, can we also generate a getter `a_or_default` that is implemented as `thing.a.unwrap_or(Thing::DEFAULT_A)`? There is a good...

Cool! Yeah I am okay with it being removed. That isn't the only part of my proposal though so I am keen to hear your opinion on the remaining points...