Release 1.0.0

[c42f]

As discussed over at #522, it's almost time for a 1.0.0 release. Personally I think there should be no great breaking changes here and we should try to make it compatible with the status quo of the last year or so. However, we can take the opportunity to make it as consistent with the final state of julia-1.0 Base as possible via a few targeted deprecations (with proper depwarns).

Here's a TODO list (moved from prior discussion at #522). Feel free to add or suggest items.

• Triage past issues & add any v1.0 milestones
• Triage current PRs & add any v1.0 milestones
• Deprecations
  • Remove v0.9 deprecations (Drop Julia v0.7 support, remove deprecations #525)
  • Deprecate SDiagonal in favor of Base.Diagonal Replace SDiagonal with LinearAlgebra.Diagonal of SVector #531
  • Remove deprecated FixedSizeArrays module
• A way forward for constructors
  • Make sure we have a strategy for Inconsistencies with multi-argument constructors #518 (probably WIP/RFC: Implement SA[...] syntax for SArray literals #633 or WIP new @SA macro and comprehension support #636)
  • Deprecate (most of?) the zoo of constructor macros (replace with WIP/RFC: Implement SA[...] syntax for SArray literals #633 ?) but keep them around in the 1.0 release cycle. Can be soft-deprecated later
  • Constructors with generators or ntuple like syntax Constructing StaticArrays with generators or ntuple-like syntax #97 Can be done later
  • Fix SVector{0}(::Vector) will not construct #520
  • Fix error creating empty MVector #557
• Revisit axes; SUnitRange etc to consider whether these design changes should go into 1.0 Too big for 1.0
  • Tidy up usage of SOneTo (follow up of Add SOneTo as AbstractUnitRange to represent axes(::StaticArray) #534; see also export & document SUnitRange #620)
  • Export of SUnitRange export SUnitRange #474
  • Consider modernizing & merging WIP Return SUnitRange from indices(::StaticArray) #150
• Resolve fallout from Fix all the things #503 where possible (eltype becoming Union{}) cf. Adding n x 0 matrices results in Union{} eltype #528
• Consider whether we can avoid promoting MArray to SArray quite so often Broadcast return type for MArrays #327

[musm]

Presumably the FixedSizedArrays compatibility layer can also be removed?

[mschauer]

Yes, it is deprecated and was vendorised in the only dependence: JuliaGeometry/GeometryTypes.jl#153

[c42f]

Good idea, see #600.

[chakravala]

Will release v1.0.0 have any breaking changes?

[c42f]

Probably a few more deprecations to come during cleanup but nothing specifically on my mind. Currently it seems that bumping major versions of widely used packages is a bit more disruptive than would be ideal, so it would seem best to wait until we have a batch of breaking changes.

There's no plan for a major rewrite or large change in the APIs though; it's mostly incremental maintenance at this stage.

[tkoolen]

Just wanted to say thanks for all the effort you've put into the package lately, @c42f!

[c42f]

Thanks Twan, I'm slowly chipping away at cleaning a few dark corners of the implementation :-)

[mateuszbaran]

Could we have #783 in 1.0?

[c42f]

Yes indeed 👍

[chakravala]

What's the 1.0 timeline?

[c42f]

No specific timeline. Releasing major versions is kinda disruptive so I wanted to make the 0.12 -> 1.0 transition "worthwhile" in that it cleaned up a few things at once.

But resolving all of the big list of "desirable issues" above is more than I can bite off at the moment, so at this point I think it might be best just to make 1.0 the next major release (in the near future) and deal with the thorny problem of axes and SUnitRange later on.

Looking back at the list of issues at the top of this thread, most of them are more desirable than necessary for 1.0 anyway, as many are bug fixes and other things which aren't breaking.

What do you think @andyferris?

[andyferris]

We should clean up the macros a bit, probably. I see what you mean by a lot being desirables. Honestly - a fundamental change like a really good treatment of axes/keys might warrant a future 2.0 release if it turns out to break dependent packages. Basically I’m in on your plan, @c42f.

[c42f]

Agreed it would be nice to clean up the macros somewhat, maybe deprecating a little questionable functionality if there's any left.

My general thoughts about the macros are that we're still not in a position to deprecate them soon because we haven't landed on a satisfying solution for things like @SVector rand(4). This syntax is just so darn attractive because it exactly mirrors the Base syntax which makes it really easy to remember, and I see people using it constantly. Of course it's pretty dissatisfying in other ways, but until a better alternative appears...

[c42f]

Of course it's pretty dissatisfying in other ways, but until a better alternative appears

Well, @tkf just reminded me about StaticNumbers.jl; I suppose the "correct" solution in some sense would be rand(static(4)). Still not ideal for syntax but at least it has semantics which exactly mirror Random.rand.

[tkf]

I was jus writing "Why not rand(static(4))" 😄

Alternatively, maybe we can use rand(SVector{4}) if Random.jl starts allowing rand(NTuple{5,Int}) JuliaLang/julia#35856?

[c42f]

Alternatively, maybe we can use `rand(SVector{4})

Actually this already works. But I've never felt really happy that it's semantically compatible with Base so I don't think it's a replacement.

[tkf]

Oops, I should've checked if it works before posting it. But why it's not a replacement? I think it'd be nice if you can get a random data structure with a generic API like rand(data_structure_with_holes) where a type is one way to specify a data_structure_with_holes.

[c42f]

Sure, it's fine in that sense, and it's quite compatible in meaning with things like rand(UInt32) so I shouldn't be too dissatisfied :-) Perhaps it's more just a user interface thing - it's nice to have an analogy to Base which is as exact as possible in terms of the syntax for generating random Arrays. As far as I've noticed people do prefer writing @SVector rand(4) over rand(SVector{4}).

[tkf]

I don't think shooting for Array-compatible API like rand(4) scales well. There are too many places Arrays are special-cased (perhaps rightly so). I think it's better to have a predictable API that composes well.

Having said that, it may be reasonable for SArray to be special-cased since it is probably the most frequently used non-wrapper array type.

[mateuszbaran]

Are there any changes needed for 1.0? Or could we have it released?

[c42f]

I think if you need it, it's probably best to release it.

Obviously I'd like to have time to fix more things and carefully assess the state of it ;-) But I don't have it, and I can't see anything really blocking holding us up.

[mateuszbaran]

I don't strictly need it, I'd just like to make some cleanup in HybridArrays.jl and Manifolds.jl that depends on SizedArray changes and structured matrix multiplication. For example I am seriously thinking about copying SizedArray to HybridArrays.jl to fix this issue: JuliaArrays/HybridArrays.jl#23 . So for example I'd like to know if it's worth waiting for the next version of StaticArrays or should I just copy that code?

[c42f]

Sounds like you need it to me! Let's release.

[c42f]

JuliaRegistries/General#25375

[andyferris]

Yay!

So, our work here is done, right? :)

[mateuszbaran]

Thanks! I hope there won't be too many problems across the ecosystem 🙂 .