Deprecate this package in favor of package extensions?

[fredrikekre]

trafficstars

Julia 1.10 have support for "package extensions" (https://pkgdocs.julialang.org/dev/creating-packages/#Conditional-loading-of-code-in-packages-(Extensions)). Instead of packages using StaticArraysCore as a "hard" dependency, which is always loaded, it seem better to recommend using StaticArrays directly as a weak dependency.

[mateuszbaran]

I think this makes sense. I will add a note to readme of StaticArraysCore.jl when a stable version of Julia is released with package extensions.

[nsajko]

Instead of packages using StaticArraysCore as a "hard" dependency, which is always loaded, it seem better to recommend using StaticArrays directly as a weak dependency.

This seems like a false dilemma, as it's currently possible to use StaticArraysCore as a weak dependency from a package extension. And it seems to me that this is actually the best of both worlds?

I'm currently creating a new package for sorting tuples, and I realized that it would make a lot of sense to add a package extension to support static vectors (in addition to tuples). Should I have a weakdep on StaticArrays or on StaticArraysCore?

[mateuszbaran]

I think benefits of using StaticArraysCore as a weak dependency are quite slim. Anyone who would like to use sorting on static arrays would probably load StaticArrays anyway? In which case you can make StaticArrays your weak dependency and be able to use more features to implement the extension.

[oscardssmith]

It's actually much worse than this. The split in functionality makes it impossible to implement a StaticArrays extension correctly (since the extension needs to be on the StaticArraysCore types, while some structs needed to extend operations only live in StaticArrays). For example, see https://github.com/JuliaArrays/ArrayInterface.jl/pull/451. If there aren't objections, could we move all of the StaticArraysCore code into StaticArrays and make StaticArraysCore just an alias for StaticArrays?

[mateuszbaran]

What's the issue with 3rd party generated functions? I would expect that correctly implemented generated functions should work fine.

[oscardssmith]

The example is the intersection of https://github.com/JuliaArrays/ArrayInterface.jl/pull/449 with this method for https://github.com/SciML/RecursiveArrayTools.jl/blob/e0f1b1ddc98671ade78fb4fd89339224e145fb95/src/array_partition.jl#L121 ArrayInterface.ismutable(RecursiveArrayTools.ArrayPartition(SVector{1}(50.0), SVector{1}(0.0)))

[mateuszbaran]

Well, as far as I can tell that should not be a generated function but rather a normal one and rely on constant propagation and Julia's compile-time execution.

[oscardssmith]

that probably is true. however the separation still has other costs (since it makes most of the operations in StaticArrays into type piracy)

[mateuszbaran]

Anyway, I'm fairly indifferent regarding removal of StaticArraysCore as long as I'm not the one handling all the issues it would cause.