I think this should work (I haven’t used it yet): use Revise.jl, prototype with NamedTuples, once +/- set turn them into a struct. You can use a constructor for the NamedTuple as provided by Parameters.jl: MyType = @with_kw (a=1, b, c=3), then later replace it with @with_kw struct MyType ....
Edit: doing dispatch on the NamedTuples will be not easy/possible though.
That is what I do. I have configured my editor (emacs in my case, but this could probably be done in any serious editor / IDE) so that it performs this kind of search/replace for me. As long as you keep your type definition in one file, it is really easy to work in this way.
You can also define constructor functions with a non-numbered name so that client code can create instances of the correct type without having to know about the current iteration number.
Maybe an example is worth a thousand words:
# Export a non-numbered name
# Forward exported non-numbered functions / constructors to numbered ones
# Such definitions will disappear when the structure is stabilized and
# renamed "Foo".
Foo() = Foo_1()
# Bump this number when modifying the struct
# Update all uses in the relevant scope (file/module)
# this should be as simple as a find/replace
Foo_1() = Foo_1(0)
# External use:
# client code doesn't need to be adapted to the internal numbering in the
# but you *see* that the structure has changed (useful to avoid
# hard-to-debug errors when different types have the same name)
Then with Revise.jl one could change the fields of Foo as much as you want without restarting and strip off the @flexible once it’s “frozen”. It would have a few restrictions, but at least it would work in functions
My usual approach while prototyping is to put the new types in a temporary module inside a temporary file and just include that file multiple times while I sketch out the design. Once the sketch is done, the structures get copied into the package I’m working on. This is kind of ok, but awkward if the new structures need to interact with the rest of the package in a meaningful way.
Having said that, I like this idea of @flexible struct a lot more. It’s very simple, yet captures a lot of the behaviors you would want from this kind of thing.