Lines Matching full:would

6 Providing a way to translate between Protos and Emboss structures would allow
12 For each Emboss `struct`, `bits`, `enum`, and primitive type, there would need
26     It would also require significantly more flexibility, and therefore more
75 A future Emboss string or blob type would translate to Proto's `string` or
139 An Emboss union construct would be necessary to take advantage of runtime space
160 ID: since a change to a field's start location would be a breaking change to the
202 Thus, for Proto2, `enum`s would produce something like:
217 which would be included in structures as:
278 **These fields would still need to be set correctly when translating *from*
330 include untranslatable entries (e.g., an Emboss `Int:16` would stored in a Proto
336 Since the Proto wire format is extremely stable and documented, it would be
349 means that every array in the structure would have to maintain a cursor during
354 that we can send protos to/from microcontrollers: this would be an alternative
362 code.  On top of the standard Proto generator, we would have to implement a
370 Emboss was designed with the notion that some backends would need their own
394 There are cases where it would be useful to generate a microcontroller-friendly
397 For most `message`s, it would be relatively straightforward to generate a
428 The main issue is that it would be difficult to maintain equivalent