@jtdavis777 Hello, I'm sorry to disturb you. Regarding this modification, I tried running generate_code.py, and found that this script modified a large number of files. However, I don't think those are related to my modifications. Do you have any suggestions on this?

hey! I just pulled master and ran the code gen script for the root directory, and had no changes. are you rebased on latest master? I would recommend going through the same steps and reporting back -- check out master and run the script, see what happens, then go to your commit and try again. let me know!

I switched to the master branch and used the flatc program that I had compiled. I successfully obtained the modified content (7 files, all related to my current modifications). I'm going to try updating now.

@jtdavis777 Hello, could you spare some time to review this PR? Thank you very much!

Hello! I know effectively nothing about rust :( and do not feel confident in merging this code without having review from someone with a bit more experience and context in the flatbuffers rust implementation. I can, however, kick off the pipeline and make sure all is well there -- I do not see any tests provided which cover this new functionality, would that be something you could work on?

@jtdavis777 Thank you for your reply. I have already conducted the relevant tests.
@aardappel Hello, could you spare some time to review this PR? Thank you very much!

Could you also please fill in your PR description?

Could you also please fill in your PR description?

done.

Don't know Rust either, but this seems mostly fine.. surprised we have serde serialize by string, but that is apparently a problem of the existing code already.

If anything, generating error strings deep down in low level code like this seems bad design to me, it should return something from which higher level / user code can decide to report an error, and how. In this case, an unknown variant isn't even an error, it is an expected thing part of forwards/backwards compatibility so generating errors is even more inappropriate. This should probably return an Option type instead?

This should probably return an Option type instead?

The serialization and deserialization of the type T generated by flatc is the core of its functionality and necessary. However, implementing deserialization for Option<T> is a topic worth exploring, as it involves changing the implementation of deserialization, especially for binary types that may result in unexpected outcomes. I hope to use new issue to involve people familiar with flatbuffers and rust in the discussion

@aardappel Hello, I would like to ask if the differences in ideas regarding implementing deserialization features for Option<T> will affect the merging progress of this PR? So far, I need to use the T type that implements deserialization features, and I don't need the Option<T> type that implements deserialization features

I was referring to replacing Result<Self, D::Error> with an Option<Self>, not serializing Option. See my previous message as to why.

I was referring to replacing Result<Self, D::Error> with an Option<Self>, not serializing Option. See my previous message as to why.

refer: https://github.com/serde-rs/serde/blob/master/serde_core/src/de/mod.rs#L561

In my understanding, the serde library has already defined the Result return type, and it is impossible to replace Result with Option unless we change other serialization systems or modify the source code of this project.

If we consider modifying the source code of the serde library, the problem is that this serialization feature has been widely used and it is impossible to modify it to Option

If my understanding is incorrect, please provide the source code at your convenience so that I can understand your thoughts

doc: https://serde.rs/impl-deserialize.html

Ok, that is interestingly bad design, but that's not your fault, so LGTM.