Agreed, but I don't think v0.1 is necessary, this could be merged in much earlier than that. This is an easy beneficial change.

Alternatively, we could drop the idea of making clients manage the options at all, and either A) rewrite tox_new() to generate a non-running instance with the default options, allowing the client to set options before the first tox_iterate() and have the first call of tox_iterate() actually do the initiation currently done by tox_new(). Or B) same as the above but add tox_init() so the flow would be tox_new() -> set_opts() -> tox_init() -> tox_iterate(). Then clients don't even need to know about that struct.

A) Is bad because nothing prevents users from trying to set options after tox_iterate() is called. The option setting could be simply ignored at that point, but imposing a restriction that option function should be called only before tox_iterate() sounds like artificial limiting.

B) Pretty much the same issue as in A).

I like the idea of the Tox_Options struct, it can be used only in tox_new() call, so there is no artificial restrictions like "Don't set options when iterated at least once!", instead this restriction is enforced by the way the code is written, you simply can't set options at any other point, nothing else accepts Tox_Options, so I don't think we need to remove Tox_Options.

@nurupo I renamed this to something more obvious, and moved the milestone to v0.0.5. If we're going to do this. We might as well get it over with now.

Edit -- uTox already supports this method.

For v0.0.5:

• Mark the struct as deprecated.
• Find a way to avoid duplication of the struct contents (make apidsl generate .c files?).

For v0.1, we can then actually remove it. Its existence doesn't do much harm at the moment, and delaying its removal gives client and bindings authors time to update.

CC: @zetok @SkyzohKey for client updates.

AFAICS, this will need:

• marking the struct as deprecated;
• additions to apidsl (e.g. needs to generate a .c file with the struct definition, malloc/free functions, some way to hook in the "default" function for the allocation function);
• changes to the build system (needs to be aware that a .c file will be generated);
• tox.c to use the accessor functions instead of accessing pointer members directly;
• the clients to update to use the accessor functions;
• all bindings to update as well.

I'd update Ricin once I know what changes needs to be made. :)

#333 does point 4 (tox.c using accessor functions).

#1825 does this. Assigned to @sudden6 because that PR fixes this issue.