Why not to allow [packed = true] for all repeated field?

[Atry]

When I set [packed = true] on a nested message field, I receive this error:

[packed = true] can only be specified for repeated primitive fields.

I wonder why it is disallowed. The output for packed nested field list as the below:

The field number and wire type LENGTH_DELIMITED.
Length of all elements.
Length of the first element.
Content of the first element.
Length of the second element.
Content of the second element.

...

Length of the nth element.
Content of the nth element.

[Henner Zeller]

On Sun, Jan 17, 2010 at 18:59, Atry <pop....@gmail.com> wrote:
> When I set [packed = true] on a nested message field, I receive this error:
>
>> [packed = true] can only be specified for repeated primitive fields.
>
> I wonder why it is disallowed.

The reason is to be able to automatically distinguish fields that have
been 'upgraded' from previously non-packed to packed.
This detection can be done because the type on the wire changes for
primitive types but it would not change for non-primitive types.

An example: a non-packed repeated field for a primitive type would be
on the wire something like <tag, int-type> <value> <tag, int-type>
<value> ...
That would change for packed to something like <tag,
length-delimited-type> <length> [<value> <value> <value> ...]

While if it was a length delimited field in the first place, say a
string or a message, that type on the wire <length-delimited> would
not change, so it is impossible to distinguish just from the raw byte
sequence if this is a length non-packed or a packed repeated field.
Dropping the feature for length delimited fields (for which there is
not much saving to be expected anyway) allows for a safe upgrade path.

> The output for packed nested field list as
> the below:
>
>> The field number and wire type LENGTH_DELIMITED.
>> Length of all elements.
>> Length of the first element.
>> Content of the first element.
>> Length of the second element.
>> Content of the second element.
>>
>> ...
>>
>> Length of the nth element.
>> Content of the nth element.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to prot...@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

[Kenton Varda]

In addition to what Henner says, we felt that it wasn't worthwhile to implement packed encoding for strings or sub-messages because the savings would be very small.  The packed encoding only saves one or two bytes per element.