Thanks, those are good points.  And personally I would much rather get this done and not have to think about it in a year's time.  (I know, I'm a biased witness.)

Moritz (who rightly stands up for stability) has said more than once that he'd find any deprecation cycle (including (2)) acceptable.

Simon

On Fri, 12 Dec 2025 at 09:41, Rodrigo Mesquita <rodrigo@well-typed.com> wrote:
While it’s true that 9.14.2 and 9.16.1 may be released not too far apart, I think option (2) buys us more than you suggest:

- The timeline in which releases are made and in which releases are adopted are definitely not in sync, perhaps except for bleeding-edge users.
- GHC 9.14 is meant to be an LTS release, which makes it a strong upgrade target candidate
- I expect many users who adopt 9.14 will upgrade to 9.14.2 as soon as that’s out, yet wouldn’t upgrade to 9.16 upon its release

Therefore, I think a deprecation warning in 9.14.2 is in fact a pretty good middle ground between parking the MR 6 months vs. merging it without a warning.

For the record, I find option (2) is the best plan forward in this proposal.

Rodrigo

On 12 Dec 2025, at 08:41, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:

Thanks Jakob.  It sounds as though everyone is happy with the end-goal of the proposal, and the only point at issue is the deprecation cycle.  I think your alternatives are correct. Just to fill them out:
  1. Accept without Deprecation cycle.  The change would take effect in 9.16, in six months time.

  2. Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented.   Deprecation would start whenever 9.14.2 comes out (probably not for some months) and the change would take effect with 9.16 in about six months.

  3. Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented.   Depreciation warnings would start with 9.16 in about 6 months -- and maybe in 9.14.2 as well.  The change would take effect in 9.18, in a year or so.
I don't think (2) buys much, because 9.14.2 will not precede 9.16 by long, if at all.

(3) is a safe choice; it just has the effect of parking the actual changes for another six month; they can be merged in HEAD after the 9.16 fork.  Someone hsa to remember to get around to actually doing it though.

I'm very open to the committee's guidance -- but it's a judgement call and in the end a vote is probably the best way to decide it.

Simon

On Tue, 9 Dec 2025 at 19:41, Jakob Brünker <jakob.bruenker@gmail.com> wrote:
Yes, I'm thinking the best way forward here may be a ranked choice vote about the deprecation cycle (unless we can easily agree on a deprecation plan without one).

I think these are the main options we need:
- Reject
- Accept without Deprecation cycle
- Accept, with a deprecation warning for at least one minor release (probably 9.14.2) before it's implemented
- Accept, with a deprecation warning for at least one major release (probably 9.16) before it's implemented

Any thoughts on this or options I'm missing?

Jakob

On Tue, Dec 9, 2025 at 8:35 PM Adam Gundry <adam@well-typed.com> wrote:
I'm also in favour of acceptance. It seems there is fairly clear
consensus here to accept, the only question is about the deprecation
cycle, as discussed here:

https://github.com/ghc-proposals/ghc-proposals/pull/732#discussion_r2583974730


My view is that we should backport a warning to 9.14.2 (and any new
minor releases of earlier major series if possible), then implement in
9.16. I think that strikes a balance between making a non-broken
implementation available reasonably soon, while warning users about the
upcoming change.

Adam



On 08/12/2025 09:06, Sebastian Graf wrote:
> I'm in favour. I tend to agree that we don't want a deprecation cycle
> because this holds back actual bug fixes.
> The GHC maintainers could backport a deprecation warning to every next
> minor release to give users notice that they need to slightly refactor
> their code.
>
> Am Mi., 3. Dez. 2025 um 22:38 Uhr schrieb Erik de Castro Lopo
> <erikd@mega-nerd.com <mailto:erikd@mega-nerd.com>>:
>
>
>     Like Moritz, in favour, with a deprecation cycle if possible.
>
>     Cheers,
>     Erik
>
>
>     Moritz Angermann wrote:
>
>      > As mentioned on the ticket, I'm in favour, _with_ a deprecation
>     cycle.
>      >
>      > On Wed, 3 Dec 2025 at 20:56, Arnaud Spiwack
>     <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
>      >
>      > > I'm in favour of this proposal. It's simple, and, I would
>     argue, more
>      > > expected than the more advanced semantics that we used to have.
>     Static
>      > > pointers aren't very much used any way, so a small regression in
>      > > capabilities isn't going to be a problem.
>      > >
>      > > I did ask for an extra discussion in the Alternatives section
>     on the
>      > > Github thread, for the sake of future documentation. But this
>     doesn't need
>      > > to hold my vote.
>      > >
>      > > On Wed, 3 Dec 2025 at 15:08, Jakob Brünker
>     <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>>
>      > > wrote:
>      > >
>      > >> Hey all,
>      > >>
>      > >> our own Simon Peyton Jones proposes to simplify static pointers:
>      > >>
>      > >> Static pointers are a feature
>      > >> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/
>     static_pointers.html <https://ghc.gitlab.haskell.org/ghc/doc/
>     users_guide/exts/static_pointers.html>> that
>      > >> allows you to get pointers to expressions that are valid
>     across different
>      > >> processes and machines.
>      > >>
>      > >> Allowing these expressions to reference certain types of local
>     bindings
>      > >> has been producing issues that are hard to fix. The proposal
>     suggests that
>      > >> instead we could just not allow that - simplifying both the
>     specification
>      > >> and the implementation without placing a large burden on users
>     (e.g.
>      > >> bindings can just be moved to the top level instead).
>      > >>
>      > >> See the proposal itself for details:
>      > >> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-
>     static/proposals/0000-simplify-static.rst <https://github.com/ghc-
>     proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-
>     static.rst>
>      > >>
>      > >> I recommend *acceptance*. The cost of trying to figure out how to
>      > >> support the current spec is not worth the fairly marginal gain
>     over the
>      > >> proposed simplification.
>      > >>
>      > >> It would be great if I could get your responses on this by
>     December 10.
>      > >>
>      > >> Thanks,
>      > >> Jakob
>      > >>
>      > >> On Tue, Nov 25, 2025 at 1:54 PM Adam Gundry <adam@well-
>     typed.com <mailto:adam@well-typed.com>> wrote:
>      > >>
>      > >>> Dear Committee,
>      > >>>
>      > >>> Simon proposes to simplify the specification of StaticPointers:
>      > >>>
>      > >>> https://github.com/ghc-proposals/ghc-proposals/pull/732
>     <https://github.com/ghc-proposals/ghc-proposals/pull/732>
>      > >>>
>      > >>> https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-
>     static/proposals/0000-simplify-static.rst <https://github.com/ghc-
>     proposals/ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-
>     static.rst>
>      > >>>
>      > >>> I'd like to nominate Jakob as the shepherd.
>      > >>>
>      > >>> Please guide us to a conclusion as outlined in
>      > >>>
>      > >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/
>     README.rst#committee-process-for-responding-to-a-proposal <https://
>     github.com/ghc-proposals/ghc-proposals/blob/master/
>     README.rst#committee-process-for-responding-to-a-proposal>.
>      > >>>
>      > >>>   If possible, please aim to make a recommendation by 9th
>     December 2025.
>      > >>>
>      > >>> Cheers,
>      > >>>
>      > >>> Adam
>      > >>>
>      > >>>
>      > >>>
>      > >>>
>      > >>> On 25/11/2025 12:18, Simon Peyton Jones wrote:
>      > >>> > Adam
>      > >>> >
>      > >>> > I'd like to submit this proposal to the Committee
>      > >>> >
>      > >>> > https://github.com/ghc-proposals/ghc-proposals/blob/wip/
>     spj-static/ <https://github.com/ghc-proposals/ghc-proposals/blob/
>     wip/spj-static/>
>      > >>> > proposals/0000-simplify-static.rst <https://github.com/ghc-
>     proposals/ <https://github.com/ghc-proposals/>
>      > >>> > ghc-proposals/blob/wip/spj-static/proposals/0000-simplify-
>     static.rst>
>      > >>> >
>      > >>> > Thanks
>      > >>> >
>      > >>> > Simon
>      > >>>
>      > >>>
>      > >>> --
>      > >>> Adam Gundry, Haskell Consultant
>      > >>> Well-Typed LLP, https://www.well-typed.com/ <https://
>     www.well-typed.com/>
>      > >>>
>      > >>> Registered in England & Wales, OC335890
>      > >>> 27 Old Gloucester Street, London WC1N 3AX, England
>      > >>> _______________________________________________
>      > >>> ghc-steering-committee mailing list --
>      > >>> ghc-steering-committee@haskell.org <mailto:ghc-steering-
>     committee@haskell.org>
>      > >>> To unsubscribe send an email to ghc-steering-committee-
>     leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
>      > >>>
>      > >> _______________________________________________
>      > >> ghc-steering-committee mailing list -- ghc-steering-
>     committee@haskell.org <mailto:ghc-steering-committee@haskell.org>
>      > >> To unsubscribe send an email to ghc-steering-committee-
>     leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
>      > >>
>      > >
>      > >
>      > > --
>      > > Arnaud Spiwack
>      > > Director, Research at https://moduscreate.com <https://
>     moduscreate.com> and https://tweag.io <https://tweag.io>.
>      > > _______________________________________________
>      > > ghc-steering-committee mailing list -- ghc-steering-
>     committee@haskell.org <mailto:ghc-steering-committee@haskell.org>
>      > > To unsubscribe send an email to ghc-steering-committee-
>     leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
>      > >
>
>
>     --
>     ----------------------------------------------------------------------
>     Erik de Castro Lopo
>     http://www.mega-nerd.com/ <http://www.mega-nerd.com/>
>     _______________________________________________
>     ghc-steering-committee mailing list -- ghc-steering-
>     committee@haskell.org <mailto:ghc-steering-committee@haskell.org>
>     To unsubscribe send an email to ghc-steering-committee-
>     leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
>
>
> _______________________________________________
> ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
> To unsubscribe send an email to ghc-steering-committee-leave@haskell.org

--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________
ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee-leave@haskell.org