FWIW, it's on my wishlist to add Maybe(T) as a built-in type. Then, we can
get rid of "has" methods -- Maybe(T) would generate getters which use the
language's preferred "maybe" idiom, whereas non-maybe T would generate a
getter which returns the default value if the pointer is null (with no way
to actually test if the pointer is null).

BTW, note that while the "default default" value of a struct is the
zero-sized struct, it is possible for a schema to specify some other
default for a specific struct field. Example:

    struct Foo {
      i @0 :Int32 = 123;
    }

    struct Bar {
      baz @0 :Foo = (i = 456);
    }

A typical implementation is to store "baz"'s default value as a static byte
buffer somewhere, and then when getBaz() is called and the pointer is null,
act like it somehow pointed to that static buffer (or in the case of
builders, initialize it to a copy of that static buffer).

It's pretty unusual for people to use this feature in practice, though.

-Kenton

On Thu, Sep 22, 2016 at 6:41 AM, David Renshaw <da...@sandstorm.io> wrote:

> On Wed, Sep 21, 2016 at 2:44 PM, Dan Appel <dan.appe...@gmail.com> wrote:
>
>> >All pointer fields can be null. Because all types in Cap'n Proto have a
>> default value, you don't need to return optionals; you can return the
>> default value when a `getFoo()` accessor reads a null. You should
>> additionally provide `hasFoo()` accessors for when the user actually wants
>> to distinguish the null case.
>>
>> I'm a little confused by the documentation on this one. What is the
>> default value of a struct?
>>
>
> The default value of a struct type is a struct whose fields all contain
> their default values.
>
>
>
>> This section <https://capnproto.org/encoding.html#default-values> seems
>> to only be about structs inside lists, but even so I'm struggling to
>> understand where I should be looking. If I have an all-zero pointer, where
>> is the default value stored?
>>
>
> There's no data to store. It's as if the struct has an empty data section
> and an empty pointer section.
>
>
> Where would I store the value a user sets?
>>
>
>
> Ah, so we're considering mutations now, and hence Builders, which differ
> significantly from Readers. If the user calls `get()` on a null pointer
> field in a Builder, you do need to actually allocate space for that field,
> in preparation for the user possibly setting values on it. Note that once
> you do this, the field will no longer be null.
>
>
> - David
>
> --
> You received this message because you are subscribed to the Google Groups
> "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to capnproto+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/capnproto.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.

Reply via email to