sob., 7 lis 2026 o 23:38 Hana Dusíková via Ext <ext@lists.isocpp.org> napisał(a):

Dear SG7 kidnapees, school-yard bullies, nerds, innocent bystanders, mountaineers,

we are going to have an 4FA SG7 telecon this Wednesday, on zoom:

https://iso.zoom.us/j/95914491492 the password is not part of the link, and you must do some self-reflection and type it o your own: [:^^_:][_]

Good luck!

The meeting starts and ends depending on your spatial and temporal location:

18:00 - 20:00 CET 🇪🇺

17:00 - 19:00 UTC 💂🏿‍♀️

19:00 - 21:00 EET 🗡️

20-00 - 22:00 MSK🪆

09:00am - 11:00am PST 🌁

10:00am - noon MST 🏔️

noon - 2pm EST 🗽

02:00am - 04:00am JST 👘

10:30pm - 00:30am IST 🪷

07:00am - 09:00am HST vo🌋

(it's also in the calendar)

sidenote: I need a scribe! ⚠️

We are going to discuss following DIS comments:

• https://github.com/cplusplus/nbballot/issues/1013 "make results of define_*_static functions structural, so it can be used directly as CNTTP"
• https://github.com/cplusplus/nbballot/issues/1006 "reflection of standard library entities" (mostly module related, it's reflection of using-declarations, which is currently ill-formed)
• https://github.com/cplusplus/nbballot/issues/1005 "disallow obj.[: private_reflection :] splicing of private members" (maybe it will go directly to EWG, depending on the response from author)

Ville, would be possible for you to  provide me a more context here, especially to answer following question by consulting with Finland NB/comemnt author.

I am mostly interesting in the author reasoning for providing a different rules for obj.*private-memeber-pointer and obj.[: private _reflection :].

I see this two as parallel, as in both situation we are using handle representing an concrete member, and not performing it's lookup.

And in rest of cpluplus the access check is consistently attached to lookup and not other usages, for example (https://godbolt.org/z/Paoh16rE1):

class X {

   struct Y { ... };

public:

   X foo();

};

X::Y x; // ill-formed, Y is private

decltype(std::declval<X&>().foo()) x; // OK, the name is private, but class not

I find the current model to be very consistent with the rest of the language, the access check is performed when forming an reflection

handle (^^X::Y or passing right member context to members_of), but afterwards no checks is performed. Without a very strong motivation,

I would be opposed to deviating to above model.

 

And these are all related papers, or papers proposing the fixes:

• P4414R0 (Ville's paper from mailing which proposed special context specific keyword)
• P4340R0 (Barry's paper from September mailing for c++26 providing generic and customizable solution) (there is a newer version here: D4341R1 (contains wording!)
• D4442R0 (Ville's paper summarizing SG7 Mattermost discussion, proposing future compatible way with P4340 without customization, only as opt-in/opt-out for structurality of types)
• P3687R1 (Dan's paper from Sofia which proposed way how to handle using-declaration, but we decided to make them ill-formed, in order to find a good solution later)
• There is no paper for the splicing (the third comment) AFAIK, this will be discussed in EWG week later in Búzios

I probably forgot some, so if anyone working on these please send them to this thread.

Also meeting notes will be edited here during the meeting: https://docs.google.com/document/d/1SQMMIlbtahNDE70SnKMfos6Mlf2sGPo0ryg0ANWjhFU/edit?usp=sharing

And I think that's all.

Hana

_______________________________________________
Ext mailing list
Ext@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2026/11/28443.php