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.

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