Date: Tue, 10 Nov 2026 15:43:39 +0100
wt., 10 lis 2026 o 15:10 Tomasz Kamiński <tomaszkam_at_[hidden]> napisał(a):
>
>
> 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/Paoh16rE1
> ):
> class X {
> struct Y { ... };
> public:
> X foo();
>
The return here of foo() should be 'Y' not 'X`, as otherwise the example
fail to convey my point.
> };
>
> 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
>>
>
>
>
> 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/Paoh16rE1
> ):
> class X {
> struct Y { ... };
> public:
> X foo();
>
The return here of foo() should be 'Y' not 'X`, as otherwise the example
fail to convey my point.
> };
>
> 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
>>
>
Received on 2026-11-10 14:43:57
