JuliaArrays / JuliaArrays/StaticArraysCore.jl
Declare StaticArrays functions in StaticArraysCore
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 17
- Forks
- 10
- PR merge metrics
- No merged PRs in 30d
Description
Avoiding a dependency on all of StaticArrays requires being able to define all needed methods using only StaticArraysCore. For example, in this Accessors PR we need to be able to this code to work:
@inline delete(obj::StaticArraysCore.SVector, l::IndexLens) = deleteat(obj, only(l.indices))
@inline insert(obj::StaticArraysCore.SVector, l::IndexLens, val) = insert(obj, only(l.indices), val)
But deleteat and insert are declared (and defined) in StaticArrays itself, so these two lines of code currently require all of StaticArrays before the compiler will even accept them.
This seems to defeat the purpose of having a separation like this in the first place. This makes me wonder, could there be a minimal set of functions in StaticArrays that you'd consider useful for interfacing from "StaticArrays-optional" libraries like Accessors?
Could deleteat and insert, and whatever other functions you think might play a similar role, be declared in StaticArraysCore, and then implemented in StaticArray?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the StaticArraysCore interface and the StaticArrays implementations of deleteat and insert, then compare the Accessors PR example. Identify the minimal set of functions that should be declared in StaticArraysCore for StaticArrays-optional libraries. Done means the declarations are available through StaticArraysCore while their implementations remain provided by StaticArrays, with the example able to load without the full package.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- api
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100