Skip to content

fix: Remove invalid keyword constructor from compdef #76

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 9, 2025

Conversation

gpeairs
Copy link
Member

@gpeairs gpeairs commented Jul 8, 2025

If you write

Base.@kwdef struct MyStruct{T}
    a = zero(T)
end

then you get two constructors:

MyStruct(; a=zero(T)) = ...
MyStruct{T}(; a = zero(T)) where {T} = ...

The first one doesn't work because T is undefined (no where clause). In other words, you can't use T in an expression for a default and expect the no-type-parameter constructor to work. I think that constructor exists for a good reason where typical structs are concerned, since it allows writing things like

Base.@kwdef struct MyStruct{T <: Real}
    a::T = 0
end

so that T can be inferred by the type of my_a in MyStruct(; a=my_a).

However, for @compdef struct MyComp{T}, we automatically generate a default containing T like _geometry = CoordinateSystem{T}(...), so that constructor will never work. This PR removes it.

Another option could have been to default to MyComp(; kwargs...) = MyComp{typeof(1.0UPREFERRED)}(; kwargs...), but T is not even guaranteed to be the coordinate type of MyComp (and in fact it's unlikely to be the coordinate type in user code, since user components should generally inherit from Component, not AbstractComponent{T}). (Also that's unhelpful if we have multiple type parameters.)

A final option would be to detect whether the coordinate type is free according to the supertype, and if it is, use the preferred unit in the no-type-parameter constructor. This seems difficult to do in a macro.

In the end it seems best to let users implement a no-type-parameter outer constructor according to their needs. So we remove the invalid constructor to avoid warnings about overriding it (which happens with built-in components WeatherVane etc in v1.4.0).

(OK, more options: We could reconsider how we initialize _geometry. I can see a bit of a hack with convert for coordinate systems of different types working when there aren't any other fields that are typed using T, but I'm not sure it's worth it. Or we could rethink caching altogether, which really doesn't seem worth it for a tiny bit of convenience.)

Copy link

codecov bot commented Jul 8, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

@gpeairs gpeairs merged commit d4a9788 into main Jul 9, 2025
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant