LEWG in Kona:
Forward P1393 to LWG for C++20.
SF F N A SA
4 7 3 7 7

Forward P1393 to LWG for a to-be-formed Executors TS.
SF F N A SA
3 4 13 3 7

Forward P1393 to LWG for C++Next.
SF F N A SA
11 7 4 6 2

Should be seen by LWG, no sooner than Belfast. Other Executors-related pieces will go to LEWG starting in Cologne for the C++23/C++Next cycle.

@tituswinters has asked that EWG see the paper.

EWG Prague Thursday afternoon: we saw the paper and will take a bit more time to understand what this paper does and why it does it in that particular way. We'll come back to it.

EWG telecon on May 21st 2020:

Properties are part of executors and are therefore one of the top items in the Bold Plan in P0592. Our main goal was to look at what's nominally a Library proposal and understand what, if anything, Language should do. In other words: don't design in isolation (neither Library nor Language).

One action item came out of this: Daisy to start a discussion with Daveed, Eric, Andrew, and Ville, regarding reflection + properties.

We didn't identify major parts of the proposal which should be done through Language facilities. We did, however, discuss a few places where better Language support might simplify properties / executors, and change what the Library parts look like:

• Canonical ordering of types.
• Compile-time mutability of datastructures.
• The lack of support for heterogeneity is something that is missing from executors.

None are blocking properties at the moment.

We took one straw poll, not as a binding decision but rather to understand what those present for the discussion thought.

Do we understand properties and think that specifying them purely in library is the right approach?

We'll revisit properties when EWG is next able to take binding decisions.

Initial LWG small group feedback provided to authors requesting a variety of updates.

Barry's P2279 will be in the coming mailing, "We need a language mechanism for static polymorphism", and might be related to this.

EWG February 2021 polls:

Poll: We understand properties and think that specifying them purely in library is the right approach.

Poll outcome: ❌ no consensus, participants do not understand properties, and might want to specify executors' customizations mechanism as a language feature.

Salient comments:

• (Strongly against) I coauthored a paper that worked deeply with properties. I understood them when I was working with them, but my brain quickly pushed it all out of my head when I was done because they were so complex to work with. I do not think specifying them purely in library is the right approach.
• (Strongly against) properties are not understood. As one glaring example - there is no way to define a single polymorphic type to satisfy all the concepts listed as "applicable" for a property. several of the properties in 0443 expose this fault. Another example is how properties for values that can change at runtime run afoul of the equality behaviour defined for the polymorphic types. Authors of properties have been known to disagree on how to answer question about what properties are for and what they are not for. properties needs to be sent back to LEWG until a majority actually understand all the mechanisms in the properties paper and how they interact or until the mechanisms have been reduced to a set that is generally understood.
• (Against) I don’t understand properties.
• Demanding a different solution at this late date, without offering any concrete alternative, would unnecessarily delay Executors, and would send authors a message that we don’t value their time.
• The property system seems complicated, but that complication does not appear to arise from a lack of language support.
• I’m not sure how I’m supposed to understand properties if the papers don’t explain it.

@JeffGarland given that Library Evolution is no longer pursuing P0443, but is instead moving forward with P2300, I don't think this should be in LWG's queue anymore.