Mauro

But how would you know when one wants to store a function in a field vs when it should be used as a property-function? I think it would still need...

But if I have, say a ODE problem which defaults to exponential growth: ``` @with_kw struct MyODE{F} tspan::Tuple{Float64,Float64} = (0.0, 1.0) objfn::F = x -> x end ``` Now, `objfn`...

I don't quite understand. Would it be solved with "Calculated fields" #18? Also note that if you specify the positional constructor (for all fields) then the kw-constructur will run through...

But can't you provide finalizers with just registering a function: https://docs.julialang.org/en/stable/stdlib/base/#Base.finalizer: `finalizer(::MyStruct, finalfn)`? I don't see how adding macro magic to that would make it more concise or more readable.

Thanks, now I get it. I think the post-create hook could be ok to implement as that would be a hook of a function of one argument. The pre-create hook...

I don't understand that work-around, maybe you can post a MWE. What do you mean with "base constructor"? An inner or outer constructor?

If the pre-create hook would be just a block of code to be inserted into the positional inner constructor, then it would have access to all variables. Something like: ```julia...

Another use case from #72 is to add a deprecation warning to a field: ``` struct AB a b end function AB(a,b) depwarn("b is deprecated", :AB) return AB(a) end ```

I'm a bit confused by the question you ask yourself. The example you give seems closer to calculated fields, no? Or what is `a` and `s`?

This would also be the way to generalize what macros (and other code) do inside the type-def. Currently `@assert` is special cased, such that it gets added to the constructor....