Dan Burkert

I'm in support of adding a reflection API, but it needs a significant amount of design. It would be nice to have a `descriptor` method which yields a [`Descriptor`](https://docs.rs/prost-types/0.6.1/prost_types/struct.DescriptorProto.html) instance,...

@vorner perhaps [this todo]( https://github.com/danburkert/prost/blob/e6aaddc259409db2193b4eae6ac064fdea319fb6/prost-build/src/lib.rs#L531) is related? I admit I didn’t try and chase down the ‘correct’ way of handling this after punting and writing the todo.

> Shouldn't this solve the issue? I think it should. I'd support adding an option to `prost_build::Config` to do that for each argument to `compile_protos`. It maybe should even be...

> That would enable enum-typed fields while allowing match expressions to naturally handle unknown values. There's an existing way to do. this: use `Foo::from_i32`, which returns `None` if the `i32`...

`prost` predates the `TryFrom` API, which is why it's a method. We should probably fix that.

Yes, I think that should be possible. Sounds like a good potential feature for `prost`.

I haven't encountered anything like this before. Could you make a minimal reproducing example, including .proto files, Cargo.toml, and build.rs?

Can you not get the same behavior by registering an `extern_path` mapping all of the symbols to the remote crate? Practically speaking I think you'd need to do that to...

see also https://github.com/gnzlbg/bitintr for safe and cross platform wrappers over the intrinsics

https://news.ycombinator.com/item?id=25183811