sob., 7 lis 2026 o 23:38 Hana Dusíková via Ext <ext_at_[hidden]>
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/jxcaqW4Y8):
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
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4414r0.html> (Ville's
> paper from mailing which proposed special context specific keyword)
> - P4340R0
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4340r.html> (Barry's
> paper from September mailing for c++26 providing generic and customizable
> solution) (there is a newer version here: D4341R1
> <https://brevzin.github.io/cpp_proposals/4340_extend_cnttp_3/p4340r1.html> (contains
> wording!)
> - D4442R0 <https://isocpp.org/files/papers/D4442R0.html> (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
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3687r1.html> (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_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2026/11/28443.php
>