Re: [capnproto] Re: Working on Swift support

[deansherthompson]

Dan, I’m now at a point where I’d work on this. Would you be up for throwing 
what you have into GitHub?

Dean

-- 
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.

Re: [capnproto] Re: Working on Swift support

[Dan Appel]

I left it incomplete - I had decoding implemented but did not finish
working on traversing the schema and codegen. I could clean up what I have
and push it on GitHub if you'd like a starting point :)

Dan

On Mon, May 1, 2017 at 8:12 AM deansher via Cap'n Proto <
capnproto@googlegroups.com> wrote:

> I'm considering using Cap'n Proto for a Swift project. I wouldn't mind
> picking up a partial implementation and completing it. Dan, or anyone, did
> you end up committing anything?
>
> Dean
>
> --
> 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.

Re: [capnproto] Re: Working on Swift support

[David Renshaw]

On Wed, Sep 21, 2016 at 2:44 PM, Dan Appel  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  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.

Re: [capnproto] Re: Working on Swift support

[David Renshaw]

On Tue, Sep 20, 2016 at 9:48 PM, Dan Appel  wrote:

> Does this mean that every field (including lists) is nullable? That's
> quite a shame. Looks like all my generated fields are going to be
> implicitly-unwrapped-optional, then (reminds me of objective-c translated
> into swift).
>
>
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.

However, if you were decoding Cap'n Proto messages into stand-alone
Swift-native plain-old-data structs, then yes, you would in general need to
make pointer fields optional, because otherwise values of a recursive type
(e.g. `struct Bar { bar @0 :Bar; }`) would be infinitely large.

- 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.

Re: [capnproto] Re: Working on Swift support

[Ross Light]

Just pointer fields. Data section fields are always "non-optional".

On Tue, Sep 20, 2016, 6:48 PM Dan Appel  wrote:

> Does this mean that every field (including lists) is nullable? That's
> quite a shame. Looks like all my generated fields are going to be
> implicitly-unwrapped-optional, then (reminds me of objective-c translated
> into swift).
>
> On Tue, Sep 20, 2016 at 6:14 PM Dan Appel  wrote:
>
> Oh, well now I feel silly :) Thanks for pointing that out!
> On Tue, Sep 20, 2016 at 5:53 PM David Renshaw  wrote:
>
> Those are null pointers. A `has()` accessor would return `false` for them,
> and a `get()` accessor would return the default value. See
> https://capnproto.org/faq.html#how-do-i-make-a-field-optional
>
>
> On Tue, Sep 20, 2016 at 8:44 PM, Dan Appel  wrote:
>
> Okay, I have a question. In my structs I'm running into pointers that have
> the value of 0 (the UInt64 pointer itself). What do I do with these? Is it
> an error on my end that I'm running into these in the first place? I've
> been trying to debug this for a few hours now and I can't find the source
> of the issue.
>
> Here's some logs that I got from reading CodeGeneratorRequest.ptrs[0]
> (nodes @0 :List(Node)) - link
> .
>
> I'm leaning on this being my fault somewhere in the parsing but just
> wanted to make sure I'm not missing something before I dive deeper.
>
>
> On Monday, September 19, 2016 at 6:03:28 PM UTC-7, Dan Appel wrote:
>
> Hi! I've been working on a Swift compiler plugin for the past week or so,
> and have been making decent progress. I've run into a few blind spots in
> the encoding spec (i.e. unions) but seemed to have gotten over the major
> humps.
>
> Just wanted to let people know in case somebody has tips or concerns.
>
> I'll also use this thread as a place to ask any future questions that I
> may have :)
>
> --
> 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.
>
>
> --
> Dan Appel
>
> --
> Dan Appel
>
> --
> 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.