Naming conventions for export and import members of a struct

[Jonathan M Davis]

On Sunday, May 27, 2018 21:54:42 Per Nordlöw via Digitalmars-d-learn wrote:
> The integer type in gmp-z just got export (binary serialization)
> support at
>
> https://github.com/nordlow/gmp-d/pull/8
>
> Next up is import (binary deserialization).
>
> What's the preferred D-style naming convention for wrapping
> exporting and exporting to binary formats?
>
> I'm thinking
>
>      Z.to!(U[])
>
> for exporting and
>
>      Z(U[])
> or
>      Z.from(U[])
>
> for importing but I'm not sure.
>
> Phobos' std.bigint doesn't have any binary serialization so we
> can't mimic that.

In general, I'd advise against using the function name to. If you use it,
then to!(U[])(myZ) and myZ.to!(U[])() will do different things, which could
be error-prone. Now, if it just results in a compilation error when you use
it with std.conv.to, then that's probably not a big deal, but it will
probably be confusing to some users of your library.

If you really want using to to do the serialzation, then for better or
worse, opCast would be the way that std.conv.to figures out how to convert
your type. If you don't want to confuse your serialization with to, or you
want it to work with to but also want a more explicit name for the function,
then you can always have opCast call another function.

If you want it to work with std.conv.to in both directions, then you should
be able to do that by overloading opCast for serialization and adding a
construtor for deserialization. Then which is called depends on the
direction of the conversion, and there's no need for a from function.

Now, if you need extra arguments to the functions (as a quick glance at that
PR seems to indicate), then std.conv.to isn't going to work, in which case,
I don't think that it's a great idea to try to reuse the name, since at that
point, it's a bit like overloading an operator to do something different
than it normally does, since you're replacing a standard function with one
that works differently rather than just providing a way to use a type with
the standard function.

Personally, I'd probably just have serialize and deserialize functions
rather than trying to make them look like std.conv.to, but that's obviously
a matter of preference. Either way, because Phobos doesn't really do this
sort of thing, there isn't any kind of "official" style or convention for
functions like this. It's ultimately up to you and what you like best. I'd
just advise that you be careful with overloading to, because if your type
_looks_ like it works with std.conv.to but doesn't, that could be confusing
and error-prone. I'd advise treating the name to a bit like an operator that
you overload and thinking of it that way.

- Jonathan M Davis