Chapel project meeting: 2026-01-13 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2026-01-13 at 10am PT
Join the meeting using this Teams link

---

Prior to the meeting, propose any agenda items using comments below. After the meeting, rough notes will be added in comments.

Typically, these meetings consist of:

• News: Quick updates or announcements to keep people in the loop on key efforts or topics
• Demos: Have something cool to show off? Do it in a ~5-minute demo
• Short Topics: Have something that needs a quick discussion, description, or straw poll? Propose a ~5-minute discussion topic
• Longer Topics: If you have a topic needing more time, propose it with an estimated duration and we'll try to fit it in.

If you'd like to propose an item in any of these categories, please reply to this discussion.

In addition to the above sections, we have some standing agenda items, such as:

• Triage: What is the state of testing and are there issues that need more attention?
• User Issues: What new user issues have come up in the past week, and which should we prioritize?
• Q&A: Have something you want to ask, but not on the clock? We'll open the floor to Q&A as the official meeting wraps up.

[DanilaFe]

I'd like to talk about the following language design issues. I don't expect to get through all of them, but I'm keeping them all here in one place.

• Confirming our approach for unifying sibling classes during return type inference. Discuss here: (How) should return type inference work with sibling classes? #28276
• Can we delete the minimal modules, which today are not used by anyone?
• We currently have a special exception that allows const fields to be mutated in methods called directly from an initializer. Issue: Fix inconsistency in modifying const fields after init this; in initializers #28279
• Confirming our approach on &&/|| for classes, regex matches, and integers. Discuss here: [Bug]: logical operators do not work on nilable classes #25382 (comment)
• The interplay for forwarding and POI is odd, arguably incorrect, and certainly causes bugs. Should we change it? Mildly-related issue: [Bug]: improper interaction between forwarding and POI causes hysteresis #28246
• Should we distinguish between "generic" and "instantiable" fields, to self-consistently allow generic type fields in types?
• How should .type behave on array slices? It's strange today, but there isn't a clearly superior alternative to me. How should .type and runtime types work with array slices and views? #28284

[jabraham17]

I would like to re-present editions as described in #28197 to ensure everyone is on the same page

[arifthpe]

I would like to talk about our schedule for deprecating and removing old previous release versions from our Spack package: #27818

[lydia-duncan]

Here's the slide I presented at today's meeting

[bradcray]

Agenda / Notes

News/Announcements

• Set release dates for Chapel 2.8:

  • Feb 26: Feature freeze
  • Mar 4: Code Freeze
  • Mar 5: Doc Freeze
  • Mar 12: Release Day

• Jade will be presenting Chapel and Arkouda at FOSDEM on Feb 1:

  • https://fosdem.org/2026/schedule/event/JRDVNU-chapel/

• HPSFCon: Daniel, Jade, and Engin have submitted talks to the main track

  • also drafting outline for half-day Chapel-focused meeting, Mar 18

Triage Status

• Daniel: mid-rotation update
  • ongoing timeout due to a sys config change breaking ofi fetching AMOs (Brad)
  • same config: something about missing Cray module (Anna/Daniel?)
    • Anna: Had forgotten about this... Should she do more here?
    • Daniel: Thinks we disabled libsci, temporarily, but can re-enable now
  • Dyno types converter test -- reviewing Ben's PR to fix (Daniel/Ben)
  • Couple memory safety issues due to memcpy issues (Jade?)
  • New failure with debug info configs (Jade)
  • 16-hour timeouts on one of our systems (Engin/ops?)
    • Lydia: Could a node be down that's hanging up ability to proceed?
    • Daniel: Uncertain, could be... Some cases do get through...
    • Engin: One job timed out during its build, suggesting it was running

User Issues

• Lydia: weekly report
  • 1 new user issue: Alpine Linux installation issue
    • have PR open with additional step needed added to documentation
    • Jade merged this morning
  • 3 user issues resolved:
    • incorrect chplcheck indentation rule (Jade)
    • fixed stdout comparisons (Brad)
    • documentation of transmute() routine (Jade)

Demos

Discussion Topics

• Daniel: Confirming approach w.r.t. unifying parent class return types

  • (How) should return type inference work with sibling classes? #28276
  • proposal, in brief:
    • returning two child classes unifies to parent
    • returning two top-level classes does not unify
    • returning nilable and non-nilable unifies to nilable
    • returning different memory management strategies doesn't unify
  • all in favor of proceeding

• Anna: Schedule for deprecating previous release versions from Spack

  • When can we deprecate old Chapel versions in our Spack package? #27818
  • formula has accumulated all Chapel versions from Chapel 2.0 onwards
  • don't have testing of all prior versions of Spack package
    • so, low confidence they're still working
    • not uncommon for Spack updates to break old packages
  • so, can we have a deprecation policy for older versions over time?
    • older versions can still be installed manually
  • and also for removing them
    • Dan: removal of deprecated versions now automatic by Spack maintainers
      • new releases cause previously deprecated versions to be removed
      • release cadence expected to be ~every six months now
      • so think of that as the rate at which things will be removed
  • Lydia: How long are old versions of Spack available?
    • Dan: pre-spack 1.0, everything was in one repo
    • now, Spack infra is Spack repo and packages are in spack-packages
    • permits Spack infra to be developed independently of package repo
    • but, git never forgets, so old versions are always there
    • but expectation should be that most users are using recent infra releases
      • and some snapshot of spack-packages repo
      • some sites have forked repos so they can have their own package mix
      • can't assume all users will use one thing
      • but should focus on spack-packages repo for Chapel
  • Lydia: What would prompt/force users to upgrade to new version?
    • Dan: handshake between infra and package repos
    • new versions of infra will force you to use compatible packages repo
    • Spack won't force you to update, say, given version of Chapel on system
    • However, another package like Arkouda may force a given version of Chapel
    • Similarly, if Arkouda has a ceiling version of Chapel, could break dep
  • Engin: worries that only supporting latest version would be too aggressive
    • Anna: Agrees now that discussion has occurred on issue
  • Engin: Current proposal?
    • Anna: 2 versions back
    • Arkouda dependences add complexity, though, if not kept up-to-date
      • so maybe "N=2 + whatever more's required to keep Arkouda working"
  • Jade: Say Arkouda says it needs 2.4+ and Chapel only supports 2.5+
    • why would this break things?
    • Anna: Because Arkouda versions haven't been floors, but ceilings
    • e.g., currently requiring something between 2.0 and 2.5 for newest
      versions of Arkouda
    • Dan: Your close interactions with Arkouda could help here
  • Brad: Is Arkouda ceiling intentional / for a good reason or arbitrary?
    • Seems like given our nightly testing, a floor would make more sense
    • Jade: Agrees... seems weird that older version has no ceiling, but newer does
    • Lydia: Maybe a process update thing on their part
    • Engin: Thinks Arkouda package was updated yesterday or day before
      • so not being neglected
  • Engin: Doesn't think our deprecation policy should be influenced by Arkouda
    • Rather, should use our deprecation policy to update Arkouda's formula
  • Anna: E4S entangles things a bit because of the versions it uses (?)
  • Anna: Also inability to build Arkouda would break CI for Spack itself
  • Anna: So if we pick reasonable value of N and communicate with Arkouda,
    should be OK
  • Anna: Any objections: Support latest release and two prior versions
    • e.g., today, we'd support 2.5-2.7 under this policy
    • Lydia/Engin/others: Sounds good
  • Brad: Example of how Spack infra updates could break old versions?
    • Anna: Maybe less likely now that Spack 1.0 is out
    • Anna: Maybe more likely--Chapel dependence is deprecated, but we didn't
      express dependencies correctly
    • Dan: Also cases of patches we apply that may no longer be necessary,
      require updates, etc.
    • Broader supported range implies more opportunity for things to go wrong

• Daniel: Can minimal modules mode be removed?

  • believes they're generally unused today
  • also introduce a maintenance burden
  • Lydia: agrees likely that nobody's using it
    • thinks putting in a deprecation would be kind
  • Brad: thinks this was developed for our use only, not end-users, s.t.
    we could remove without going through deprecation cycle
  • Brad: found this useful for exploring resolution changes, but doesn't do
    much of this personally anymore
    • e.g., given these definitions of foo() and this call, what is resolution doing?
      (without dragging in all the modules and their complexity)
    • if nobody's using it today, we should remove it
    • would be nice to have an equivalent of this in Dyno going forward
    • Daniel: agrees, but we don't have it today
  • Jade/others: What happens if run over whole test directory?
    • Brad: never intended for that; just for exploring programs in isolation
      • e.g., no support for strings, locales, etc. -- anything implemented in modules

• Jade: sync-up on editions and implications for developers

  • making sure devs are aware of editions and documentation of them in PR
    • Expand editions docs for what is considered for inclusion in an edition #28197
  • edition defines a version of the language, independently of compiler
  • two kinds of changes, both covered by editions:
    • breaking changes:
      • altering or removing stable feature
    • non-breaking changes:
      • altering, deprecating, or removing unstable features
      • adding new features
  • wrote up description of how each of the above relates to editions
  • preview edition becomes named edition over time
  • [more details I didn't capture live in the meeting -- see PR for details]
  • implications for adding new features:
    • can't just add new stable features b/c changes current default edition
    • instead, can add new features as unstable features, ignoring editions
      • makes features instantly available to users, if OK with unstable
    • when ready to be stabilized, make stable in preview edition
      • then preview edition becomes new edition over time
    • a feature can be in both preview edition and default edition (unstably)
  • Lydia: Thinks a visual in docs would aid this description as well
  • Engin: Has been wrestling with "unstable pool"
    • viewing unstable features as extensions to the language has helped
  • Daniel (in chat): the way I see it: there's a "pool" of unstable
    features which can change at any time (particularly due to
    compiler versions). Language editions circumscribe such pools
    and mark them "stable" (requiring those features in those
    editions not to change, though they can change in other
    editions)
  • Daniel: Take child class inference from earlier in meeting, for example
    • in effect, changing the return type mechanism
    • so, less of a discrete feature being dropped in, more change to language
    • can't really opt in or out of return type inference
    • Jade: changing a stable feature is a breaking change
      • but this case could be viewed as adding an extension to the new feature
      • and then warn unstable only for cases that have changed
        e.g., unifying child classes only would generate warning
    • Daniel: feels anxious b/c can't really opt out of compiler doing this
      • if relying on compiler not being able to unify, can't help with that
    • Lydia: Lydia's gut is that what Daniel's proposing should go to preview
      edition
      • not many people relying on --warn-unstable b/c so many things are...
  • Daniel: thing that makes sad about this is that, in practice, will take
    forever for improvements to make it to the user
    • e.g., child unification example feels like no-brainer, uncontested
  • Engin: Given that Dyno set out to fix resolution issues, seems like there
    may be a lot of resolution-based changes that come online with Dyno
    • imaginable to think that first new edition / default edition is the slew
      of new issues that Dyno brings in when it becomes the default
    • Daniel: Seems attractive; do we want that switch to be the default soon?
    • imagines there being a release or two between Dyno being default resolver
    • Engin: Doesn't think child1/child2 is blocking users today, so not
      worried about having it super-soon
    • Daniel: Developer burden to make sure that all features turned on over
      past n months are not forgotten
    • Lydia: This is why editions should include list of features that they enable
    • Jade: If it goes into preview edition, it's added to this list
  • Jade: To Jade, a bit of extra process in adding and changing features is
    the price of stability; if we want stability, there will be some overhead
    • in many ways, what "unstable" is for is to lower that barrier to entry
  • Daniel: Something that may be missing is some sort of example of each of
    these rules being applied
    • as a dev, here's how I decide, here's how I proceed, what it takes to
      only make this resolve in a given edition
    • concrete examples over time to serve as precedent for other decisions
  • Brad: Thinks that programs that don't work don't need to keep working
    • Daniel: Concerned about type system/safety guarantees and changes to it
    • Engin (in chat): Crux of stability is to avoid "my program was
      running, now it doesn't". Non-compiling behavior is by
      definition out of it, in my personal view FWIW.

Queued up for a future week

• Daniel: Current exception about modifying const fields via method in init()

  • Fix inconsistency in modifying const fields after init this; in initializers #28279

• Daniel: && / || and boolish types

  • [Bug]: logical operators do not work on nilable classes #25382 (comment)

• Daniel: forwarding and POI interaction

  • [Bug]: improper interaction between forwarding and POI causes hysteresis #28246

• Daniel: Should we distinguish between "generic" and "instantiable" fields?

• Daniel: How should .type behave on array slices?

Post-meeting

Office Hours / Q&A

TODOs / Open Issues