Chapel project meeting: 2026-04-28 (agenda items, meeting link, notes)

[github-actions[bot]]

This discussion is for the weekly Chapel project meeting.

Date/Time: 2026-04-28 at 10am PT
Join the meeting using this Zoom link
See the Chapel community calendar for additional details and dial-in options

---

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.

[bradcray]

I've got a follow-up discussion topic to last week's—this one on defining record comparison operators in module code in the preview edition (#28708)

[lydia-duncan]

Here's today's user issues slide:

[bradcray]

Agenda / Notes

News/Announcements

• Engin's "My Open Source Experience" podcast now available:

  • theme: his open-source career through the lens of mentoring
  • full episode: https://www.youtube.com/watch?v=90tri7_uKys&t=2s
  • or, as short clips: https://www.youtube.com/@MyOpenSourceExperience/videos
  • also a new standalone episode with outtakes from season 3 interviews
    • topic: community building
    • https://www.youtube.com/watch?v=NdJm0QdddRc&t=1675s

• Nathan's presentation of Shubh's CUG work happened earlier today

  • Nathan reports it went well
  • https://builder.guidebook.com/g/#/guides/cug2026/schedule/sessions/32436801?scheduleDayPosition=2026-04-27

• Thursday deep-dive slot: potential benchmark perf review w/ Andrew Morgan (cancelled)

  • topic: performance tuning Chapel implementation of CloverLeaf
  • haven't received final confirmation yet, will update...
  • to propose a topic for future weeks, see:
    • Chapel Deep Dive & Demo meeting: topic list #27247

• Next week's Tuesday meeting:

  • Jade and I will be at UW for the annual PNW PLSE workshop
    • https://pnwplse.org/
  • need someone to run the meeting in my place
    • Daniel will do it
    • TODO: host key

Triage Status

• Ben: mid-rotation update
  • baseline: iterator issue from new PR (Jade)
  • GPUs: test of device attributes instability (Jade has volunteered to look)
  • noise, but mostly sporadic network issues

User Issues

• Lydia: weekly report
  • 1 new user issue: ** on param reals (labeled good first issue / easy)
    • Daniel: Damian raised lots of concerns about properties of exponentiation
    • Daniel/Brad's instinct: parm ** should take similar approach as var/const
  • 1 resolved user issue: auto-vectorization of 'for' loops (Jade closed)
    • happily, found it to be resolved, whether due to LLVM or chpl fixes
  • 1 old issue generating discussion: .writeBits() in IO module
    • probably needs live discussion

Demos

Discussion Topics

• Brad: Defining record comparisons as module code (==, !=, <, <=, >, >=)

  • issue: Should ==/!= on records be defined as module code or by the compiler? #28708

  • Currently, for a record 'R', the compiler defines these ops if user hasn't

  • Seems preferable to define as module code instead

    • implementation is easier to read, understand, and modify
    • implements more of the language using the language vs. clever compiler
    • avoids current compiler logic about when to create compiler-generated ops
      • a bit weird (and inconsistent with initializers):
        • "if no == operator is defined between the record types anywhere"
        • (seems like this should only consider primary/secondary op methods)
      • and maybe hard to intuit?
        • for generic record R, how generic/non- do the overloads need to be?
        • ==(r1: R, r2: R) v. (r1: R(?), r2: R(?)) v. (r1: R(2), r2: R(2))
        • does the answer differ if 'R' is a fully-defaulted generic or not?
      • spec: "Default functions to overload comparison operators are defined
        for records if none are explicitly defined."

  • Differences:

    • module version takes generic 'record' where compiler takes 'R'
    • module version will show up in candidates lists for unresolved '=='s

  • Question:

    • any obvious downsides to implementing as module code?

  • Discussion:

    • Daniel:
      • These operators are also defined before resolution
        • implies more complicated ways of defining will break this logic
        • e.g., secondary method on result of a type procedure, say
        • makes compiler seem even more weird
      • saw TODO in the PR about why distributions prefer generic version
        • old versions were defined in scope of type; new is in ChapelBase
        • matters a bit for internal module library code
          • they don't bring in ChapelBase
        • might introduce circular dependencies if such modules use ChapelBase
      • that said, still in favor of this approach
    • Brad: explaining TODO above
      • in BlockDist, we define blockDist.==()
      • calling myBD == myBD2 prefers the record/record version
      • unless "last resort" is applied
      • Jade: is where clause the cause potentially?
      • Daniel: his guess as well
      • Brad: will check
        • (and had been thinking of moving where into body anyway)
    • Jade: of the reasons above, only convincing one is fixing weirdness of
      any == squashing compiler-generated code
      • as user, don't care where auto-== comes from if it works
      • but fixing weird cases is a better justification
      • and fixing this makes it worth changing
    • Jade: if you specify an ==, what's the implication of !=?
      • getting one for free may or may not be a good thing
    • Jade: could imagine accepting this as a non-edition change
      • specfically, if it's a semantic change that's fixing a bug
      • or: shouldn't make a semantic change just to get it into module code
      • Brad: thinks it was intentional, not accidental, so not a bug
    • Daniel: thinks it is an edition-oriented rule (a semantic change)
      • considers the new semantics to be preferable / more correct / aligned
    • Daniel: forwarding continues to be a concern...
      • TODO: can Daniel create a case that would illustrate this?
    • Daniel: thinks it's good to generate != from == and vice-versa
      • Oh, but we only get one, and not the other, huh?
      • That's pretty scary...
    • TODO: implications of definining only ==/!= (and similar for <, <=, ...)
      • TODO: able to make it symmetric in both directions?
      • TODO: what do other languages do here?
        • Jade: thinks in C++, you must define them all yourself
        • Rust: must define or use decorators to auto-provide them
          • not sure what the implications are for overriding one of them
        • Python: doesn't have by default, but can create data classes to
          generate them for you
          • but if writing yourself, you write all yourself
          • Daniel: Or use spaceship equivalent

  • Proposal:

    • switch to module-based comparisons in preview edition

  • Conclusions:

    • need to follow up on TODOs above
    • no strong objections to module-based approach, modulo surprises
    • guarding based on preview edition

Post-meeting

Office Hours / Q&A

• additional discussion about:
  • having == imply !=
  • having != imply ==
  • requiring == and != to both be implemented
  • general preference for treating (==, !=) and (<, <=, >, >=, [==, !=] as
    two separate bags of operators
  • general preference for safety/avoiding laying traps for users
    • e.g., if user must define both, compiler/linter error if they don't
    • require pattern of declaration to be sufficiently similar
    • e.g., operator R.==(x: R, y: R) might require
      • might require defining operator R.!=(x: R, y: R)
      • and not be satisfied by myAliasToR.!=(x: myAliasToR, y: myAliasToR)

TODOs / Open Issues

• cancel Thursday meeting if no plans
• send Daniel host key for next week's meeting
• Daniel to create test case trying to show forwarding issue with
  module-based record == operators
• Brad to explore implications of defining == but not != and such