A key feature of Julia is that type annotations are not usually needed to achieve optimal performance.
For example, foo(1,2) runs equally fast regardless whether foo() is defined as foo(a,b) = ... or foo(a::Int, b::Float64) = .... Unfortunately, there is an important exception to this rule: writing
will discard all compile-time type information on a and b and hence incur a significant performance penalty. A common workaround to this problem is to introduce a new type parameter for each field:
This recovers the flexibility of optional typing and preserves the performance of compile-time types, but keeping the fields and type parameters in sync can be laborious.
TypeParams eliminates the fuss of generic type parameters by introducing a macro @typeparams which allows you to insert such type parameters using a simple syntax:
@typeparams struct Foo
It further supports expressing type constraints with zero syntax overhead:
@typeparams struct Foo
Finally, @typeparams plays well with other features of the Julia language:
Recently, I tried to make ConcreteStructs.jl usable in combination with Parameters.jl. My personal conclusion is that it is necessary to change Parameters.@with_kw expanding the macros in the argument expression, like Base.@kwdef.
No, @typeparams is currently not compatible with @with_kw, as @genkuroki has already pointed out. @genkuroki’s fix of making @with_kw expand its argument first works in simple cases, but I expect it would break the @assert and @deftype features of @with_kw.
Maybe @with_kw @typeparams could be made to work by deleting the macroexpand in @typeparams, but then @typeparams may also require quite a bit of extra work to make it handle the potentially vastly more complicated input.
Personally, I would love to see such improvement in native Julia without explicit usage of macros from packages. It seems quite natural addition for performance and is rare to see a situation where Any type is preferred.
resulting in additional “anonymous” type parameters. There is, of course, some abuse potential - instead of using the same type parameter for several fields (where appropriate), it would be easier for users to use the syntax above, resulting in types with (potentially) a large number of type parameters.