Mikhail Zabaluev
Mikhail Zabaluev
> Feature gates can't change a method signature. Sorry about the possible confusion, but I'm not asking to modify the signature of `format`. Just enable it under a feature gate...
> The primary problem that formatting into `fmt::Write` is that arbitrary bytes can be present in the format description. It's not immediately clear how this interacts with an output that...
> > I'm not asking to modify the signature of `format`. Just enable it under a feature gate that does not pull in std. > > This inherently requires a...
Versioning in proto files will simplify the logistics of multi-version Tendermint support in language bindings. This project need to follow (or come up with?) the best practices of managing breaking...
`derive_builder` does away with a lot of the boilerplate and is very flexible, but I think a code generator using specific knowledge of the protobuf type system would be able...
As realized in #901, a protobuf-specific generator can provide much more ergonomic API than a general purpose derive.
@avsaase > Maybe I'm missing something here but why not just generate a Rust enum with the `#[non_exhaustive]` attribute? In proto3, the enums are [open](https://protobuf.dev/programming-guides/proto3/#enum) and the language guide suggests...
> This has the same effect on the field size as `Unknown(i32)`. `PhantomData` to the rescue: ```rust pub struct EnumFieldValue { value: i32, _phantom: core::marker::PhantomData, } impl EnumFieldValue where i32:...
> I don't understand your last example though, what is expected behaviour in it? The compilation fails with: > error[E0659]: `test_case` is ambiguous This is because in the `foo` module,...
The currently promoted pattern of error handling could be enabled by an adapter trait: ```rust pub trait LiftBuf { type Output; type Buf; fn lift_buf(self) -> (io::Result, Self::Buf); } impl...