Missing unstable warning on `cyclicDist.createArray` with `initExpr`

[jabraham17]

The following blockDist.createArray procedure is currently marked unstable while design continues on it

@unstable("'blockDist.createArray' with an 'initExpr' formal is unstable and may change in a future release")
proc type blockDist.createArray(
  ...,
  type eltType,
  initExpr
)

This was added in https://github.com/chapel-lang/chapel/pull/23112, along with stencilDist.createArray and cyclicDist.createArray. While stencilDist is unstable, cyclicDist is considered stable. This means that the cyclicDist.createArray with initExpr is currently considered stable, even though it was not meant to be.

However, to mark it as unstable now would be considered a breaking change, and such a change needs to wait for a way to make breaking changes (such as a new language edition). This issue is capturing the desire to make this unstable and/or change cyclicDist.createArray with initExpr to match whatever we do with blockDist.createArray with initExpr.

Note that if blockDist.createArray with initExpr is stabilized as-is, then this issue is probably moot and can be closed

[bradcray]

Personally, I'd just consider this a bug fix and mark it as unstable if that was our intention. I don't think we should consider ourselves to be beholden to mistakes that we made between intention and implementation w.r.t. "breaking" behaviors.

[jabraham17]

That would be my preference as well, but that runs contrary to another similar decision we made recently in https://github.com/chapel-lang/chapel/issues/24857.

assocDomain.sorted() was not intended to be made stable but we forgot to mark it as @unstable, making it appear "stable". On this topic, we decided that marking it unstable and/or deprecating it would be a breaking change, even though we never intended it to be stable.

[bradcray]

I can't remember whether I was involved in that conversation or not, but I'd be very open to ripping off the bandaid on that one either. Basically, I think my philosophy could be summarized as "our community is not so big nor (from what I've seen) so rigid/concerned w.r.t. 2.0 stability that we should feel the need to hobble ourselves over "oops!" moments at this point. That is, bug fixes can be thought of as being fixes to human/team mistakes as well as mistakes in the code.

[lydia-duncan]

Chiming in - I find that appealing in this particular case. Though given that we have other, larger impact stabilization items (like the dmapped replacement), I think we could afford to let these accumulate until we have the more formal process for breaking changes, and then we would hopefully have enough breaking changes to justify making a version bump so we don't have to live with supporting two versions as long.

Put another way, I think we'll wait longer to do a 3.0 if the only change that qualifies for it is the dmapped replacement. Having some other minor changes waiting in the wings as well will encourage us to make the push sooner, which I think may be healthier in the long run. I sincerely doubt we'll have a major version change as impactful as the 1.x -> 2.0 update was, nor would I think we want one with that long of a lead time and that involved of a process. So if minor additional changes adding up pushes us closer to the 2-4 years time frame than the 5+ years time frame, say, I think that would be okay, just as long as we don't end up in a yearly-major-release mode.

[lydia-duncan]

And I think treating stuff like this particular issue this way can also help build trust that we're not immediately going back to our earlier habits