fix: Remove invalid keyword constructor from compdef #76
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If you write
then you get two constructors:
The first one doesn't work because
T
is undefined (nowhere
clause). In other words, you can't useT
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 likeso that
T
can be inferred by the type ofmy_a
inMyStruct(; a=my_a)
.However, for
@compdef struct MyComp{T}
, we automatically generate a default containingT
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...)
, butT
is not even guaranteed to be the coordinate type ofMyComp
(and in fact it's unlikely to be the coordinate type in user code, since user components should generally inherit fromComponent
, notAbstractComponent{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 withconvert
for coordinate systems of different types working when there aren't any other fields that are typed usingT
, 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.)