+1.

As a data point: in the Haskell runtime library's RPC support, I ended
up manually defining newtype wrappers around Ids for Import/Export and
Question/Answer -- this is kinda sad since the schema actually already
define aliases, but the schema compiler doesn't convey this in any way
to the code generator plugin.

-Ian

Quoting Vitali Lovich (2019-09-16 16:27:01)
>    What about strong typedefs just for "primitives" like timestamps where
>    implicit conversion is more of a concern than absolute optimization?
>
>    On Mon, Sep 16, 2019 at 12:59 PM Kenton Varda
>    <[1][email protected]> wrote:
>
>    Hi Vitali,
>    What you propose looks pretty similar to what I've had in mind for a
>    while for "inline structs".
>    I might do it more like:
>    �  �  struct Vector3f inlineable {
>    �  �  �  // `inlineable` keyword generates code that uses dynamic field
>    offsets
>    �  �  �  // from a table at runtime, thereby enabling inlining with
>    varying layouts.
>    �  �  �  x� @0 :Float32;
>    �  �  �  y� @1 :Float32;
>    �  �  �  z� @2 :Float32;
>    �  �  }
>    �  �  struct MyAwesomeStruct {
>    �  �  �  foo @[2..4] :Vector3f;
>    �  �  �  // typical use: layout is like a group, but the type is
>    Vector3f
>    �  �  �  bar @[0..1,5] :Vector3f;
>    �  �  �  // split use; useful when the inlined struct adds new fields.
>    �  �  �  baz� @[6] :Vector3f;
>    �  �  �  // incomplete use; produces compiler warning like:
>    �  �  �  //�  �  � Vector3f has been extended with two new fields; to
>    use them you must assign two more numbers.
>    �  �  �  qux� @[7..9] :List(Float32);
>    �  �  �  // inline list, always has 3 elements.
>    �  �  }
>    Unfortunately I don't have any timeline for implementing this feature,
>    and I do worry that it will be overcomplicated...
>    -Kenton
>
>    On Wed, Sep 11, 2019 at 2:47 PM <[2][email protected]> wrote:
>
>    Is there any support for strong type aliasing? I see it on the roadmap
>    but I'm guessing no progress has been done on that front?
>    The specific use-case I'm dealing with is time & wanting to ensure the
>    correct units and epoch can be used (e.g. define a function taking a
>    monotonic_clock::timepoint and return a strongly typed 64-bit integer
>    nanoseconds that's typed to represent network time so that when the
>    other side reads it it needs to reverse convert.
>    More advanced would be to be able to define a Vector3f data type that I
>    know will only ever have 3 floats that I can reuse in a bunch of places
>    without paying for the cost of it being a separate struct (.e.g it
>    would take an "offset" field number & use up offset + N). So something
>    like:
>    group@N Vector3f {
>    �  � x @N[0] :float;
>    �  � y @N[1] :float;
>    �  � z @N[2] :float;
>    }
>    struct MyAwesomeStruct {
>    �  �  ...
>    �  �  vec3 @10 :Vector3f@10;
>    �  �  vec3 @12 :Vector3f@12;
>    }
>    The actual syntax that would make sense I have no opinion on. This is
>    intended to just communicate what I would like the behaviour to look
>    like. It would ideally actually be typed in C++ too rather than purely
>    a convenience schema syntax.
>
>      --
>      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 [3][email protected].
>
>      To view this discussion on the web visit
>      [4]https://groups.google.com/d/msgid/capnproto/4e2ff46a-449c-4d45-91
>      6d-7edcd25362f7%40googlegroups.com.
>
>    --
>    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 [5][email protected].
>    To view this discussion on the web visit
>    [6]https://groups.google.com/d/msgid/capnproto/CAF8PYMimja_tJ5%3DwpM8p%
>    3DLy8D0M%2B9c5D%3Ds_EC39_wZcaUz8vOA%40mail.gmail.com.
>
> Verweise
>
>    1. mailto:[email protected]
>    2. mailto:[email protected]
>    3. mailto:[email protected]
>    4. 
> https://groups.google.com/d/msgid/capnproto/4e2ff46a-449c-4d45-916d-7edcd25362f7%40googlegroups.com?utm_medium=email&utm_source=footer
>    5. mailto:[email protected]
>    6. 
> https://groups.google.com/d/msgid/capnproto/CAF8PYMimja_tJ5%3DwpM8p%3DLy8D0M%2B9c5D%3Ds_EC39_wZcaUz8vOA%40mail.gmail.com?utm_medium=email&utm_source=footer

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/156867148561.13552.12284631351669006307%40localhost.localdomain.

Reply via email to