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