export & document SUnitRange

[tpapp]

StaticArrays.SUnitRange is very useful to unify code when I want a slice of an AbstractArray to be an SArray if the dimensions are known at compile time.

I wonder if it could be documented and exported, and thus made part of the API.

I am happy to make a PR, just wanted some feedback on this first. (Cf #32)

[c42f]

Makes sense to me 👍

It's too bad that SUnitRange still needs the L parameter, rather than being parameterized by Start and End but we can't change that without changing Julia itself.

I guess we just document clearly that the recommended way to create one of these is via SUnitRange(a,b), rather than SUnitRange{a,L}().

Other than that, are you and @tkoolen happy with the API? I must admit I haven't used this myself!

[andyferris]

Yes, I always wanted to export it.

Is it currently “feature complete” in terms of indexing other kinds of arrays?

At some point I was hoping to replace Size with this (using standard AbstractArray interfaces like axes and keys). I guess length and size should theoretically be able to rely on constant propagation.

[tkoolen]

I don't currently have a use case for this myself, but I'm generally supportive of exporting it. I too was thinking about constant prop though; @tpapp, out of curiosity, do you have an example case where using SUnitRange beats an implementation that relies on constant propagation?

Just looking at the code, I do wonder about the @pure usages in https://github.com/JuliaArrays/StaticArrays.jl/blob/1b99b91518f5cb471503c18e18ae57e9d7351ba4/src/SUnitRange.jl; a bunch of the @pure methods throw errors, which is bad. Also, there appear to be new @pure changes coming in, so this might become an issue in the future.

[tpapp]

@tkoolen: I don't have an MWE, but I don't think constant propagation can be relied on universally, it does not always happen.

Regarding the @pure, when doing a PR I could check if they are still needed. 1.2 is much better about just inferring things.