Oh boy, there were so many suggestions, I'd have to read through them all to remember which ones I ended up incorporating. There's so much text, though...

Off the top of my head, I remember that multiple people suggested that text should be allowed to contain NUL characters (not just at the end), which I agreed to. That's not terribly significant, though.

People involved on the mailing list have helped me with several design decisions. One contributor convinced me that my original syntax for unions was pretty stupid and helped me come up with something much better.

At another point, I implemented "inline" structs and lists (which are embedded into their parent without a pointer). This turned out to be overcomplicated for not all that much benefit and I was encouraged to ditch it. A week of work lost, but it was the right decision.

Contributors hacking on implementations in other languages made clear that they weren't interested in writing their code generators in Haskell, so the compiler now has a plugin system allowing code generators in any language.

This is a very incomplete list, obviously... I'd love to have more people telling me what I'm doing wrong. :)

Using colons to denote types is still ugly and feels unnecessary.

Your last annotation example confuses the @field and $annotation syntax-- string $0 :Text $qux;

> Using colons to denote types is still ugly and feels > unnecessary.

Yeah, I hear you. My personal experience is that when I look at Go code, I find it hard to parse variable definitions since the type has no separator. But I'm sure if I wrote more Go, it would get easier. I worry that there is a bit more need for Cap'n Proto schemas to be easily readable to newcomers compared to Go code. On the other hand, in Cap'n Proto there is usually an ordinal number separating the name and type anyway (though not always).

So far not many people have complained, but I could definitely be convinced to drop the colon if that's what people want.

> Your last annotation example confuses the @field and > $annotation syntax-- string $0 :Text $qux;

Eek, fix pushed. Thanks!

> Off the top of my head, I remember that multiple people suggested that text should be allowed to contain NUL characters (not just at the end), which I agreed to. That's not terribly significant, though.

This seems contrary to what the docs[1] say: > Text is always UTF-8 encoded and NUL-terminated.

Which is right?

[1] http://kentonv.github.io/capnproto/language.html

Text is still NUL-terminated, it's simply allowed to contain NUL bytes in the middle as well. It's up to applications how they want to interpret this, but enforcing the NUL byte at the end is important for apps that want to pass a char* pointer around and don't want buffer overruns if they forget to validate the NUL terminator themselves. (It's a key design goal for the Cap'n Proto implementation to protect the app from security issues as much as possible.)

The encoding page describes this a bit better: http://kentonv.github.io/capnproto/encoding.html#blobs

I see. I haven't gotten to the encoding page yet, but that sounds perfectly reasonable to me.

Small question before I get there, I imagine that such things are tagged with a length so that you can actually determine where the text field really ends then?

Yes. The actual getter for a Text field returns StringPtr, which is a simple pointer-length pair. If you want to pass that on to a C-style function you call .cStr(), with the caveat that the content is effectively truncated at the first NUL char.