I perused the source code of release 27 to conduct my periodic survey of whether we can alias strings yet or not. At work I maintain a private patch that adds aliased string parsing to the library, but I'd love to stop maintaining that. My understanding of the current state of affairs is that string_view setters and getters have been added for singular and repeated fields, but when setting the contents of the string_view argument are unconditionally copied into memory owned by a std::string. The string may or may not be on an arena, but the contents are likely to be allocated with global new, modulo the short string optimization. During parsing, the input is never aliased, regardless of the kParseWithAliasing parameter. Finally, it seems that Cord still only supports singular fields.
Given all that, I am left wondering what the purpose of the VIEW type is. If it currently has these properties, and given Hyrum's Law, should I assume that these behaviors will be perpetuated? That is, that C++ protobuf will never be able to parse a repeated bytes field with aliasing, if I understand correctly. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/bfe8c4ef-e234-4a74-88f7-404b43f6f6efn%40googlegroups.com.
