Date: Fri, 15 Apr 2022 21:05:06 +0200
haha,
I REALLY would like to have the first portable "hello module" example.
Currently, there is simply no way to have it. That's really a shame.
Am 15. April 2022 20:46:59 MESZ schrieb Gabriel Dos Reis via Ext <ext_at_[hidden]>:
>Nathan - you recount is all correct.
>
>> I know I've mentioned it more than once, but I find it unsettling, given there
>> was great opposition to there being a (two way?) mapping between file names and
>> module names, that there is a move in the direction of making file names
>> 'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>> alice.$MODULESUFFIX is taking us all the way back to the first objection above
>> about having two languages.
>
>I am not seeing any movement to make filename suffixes significant in the linguistic interpretation, by the compiler, of the content of source file. Maybe I am not looking right; but I would definitely recommend against such move. There are extra linguistic considerations that might force a toolset (not just a compiler) to require certain suffixes, but those suffixes do not determine the meaning a C++ program -- this is not different from compilers like GCC or MSVC refusing to compile in default mode files ending with ".h" or similar because they generally have other connotations.
>
>For some reasons, the topic of the "right" suffix seems to generate more passion than the topic of what can we do with modules, so maybe we are already doing a lot with modules 😝
>
>-- Gaby
>
>-----Original Message-----
>From: Ext <ext-bounces_at_[hidden]> On Behalf Of Nathan Sidwell via Ext
>Sent: Friday, April 15, 2022 11:21 AM
>To: sg15_at_[hidden]; ext_at_[hidden]; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>Cc: Nathan Sidwell <nathan_at_[hidden]>
>Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?
>
>On 4/13/22 17:10, Nico Josuttis via SG15 wrote:
>> I should add that the fact that we need
>> module;
>> at the beginning of the global module fragment was only introduced to let a file
>> identify itself as module file.
>> If we would require different suffixes, that would not have been necessary.
>>
>> But correct me if I am wrong.
>
>I shall correct you :)
>
>Here's the history (as I recall, all persons mentioned are real, and not to be
>confused with ficticious characters)
>
>* prior to me doing things with gcc, there was only 'module FOO;' as a module
>declaration at-most once within a TU. MSVC (the only compiler with module
>smarts at the time), had a flag to tell it 'this is an interface' vs 'this is an
>implementation'.
>
>* I found this unsatisfying, as it meant that there was something outside the
>source tokens that told you how to interpret them. In effect we had two languages.
>
>* IIRC, Gaby, Jason (Merrill) and I came up with the 'export module FOO;' vs
>'module foo;' distinction. But still this could be anywhere in the source
>stream. I was able to implement this functionality to a working system.
>
>* Daveed proposed an early signifier of 'hey, this is gonna be a module', should
>the actual module declaration not be first. Hence 'module;' was born. (My
>understanding was that this was driven by implementors, as they had difficulty
>entering a module-like mode not at start of compilation, and indeed it was a
>little tricky to do that. I do not know if this was also a user request.)
>
>* post p1103, the requirement that everything between 'module;' and the module
>decl come from #include came to be.
>
>Hope that helps.
>
>I know I've mentioned it more than once, but I find it unsettling, given there
>was great opposition to there being a (two way?) mapping between file names and
>module names, that there is a move in the direction of making file names
>'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>alice.$MODULESUFFIX is taking us all the way back to the first objection above
>about having two languages.
>
>nathan
>
>>
>>
>>
>> Am 13. April 2022 22:58:13 MESZ schrieb Nicolai Josuttis via Ext
>> <ext_at_[hidden]>:
>>
>> What I teach about modules is compelling. Programmers like and want to use it.
>> However, they ask how they should organize module files in practice.
>>
>> So far I cannot recommend a specific suffix (and I might never be able to do
>> that).
>> However there is one important question that IMO the standard should answer:
>> *Do we **/need /**different suffixes?*
>>
>> I understand that a suffix discussion is only of practical value.
>> But IMO the standard has to give an answer here (which has nothing to do
>> with which suffixes are used).
>>
>> Let me elaborate that in detail:
>>
>> Not having a standard suffix has interesting consequences.
>> So far we have header files and translation units.
>> But once we know what a C++ translation unit is, we can just compile them
>> all with the same compiler options or commands. Because in practice we have
>> different suffixes for header and source files, we can set-up generic rules
>> to compile our code.
>>
>> This works for any suffix, provided you know the way to tell the compiler
>> that we have a C++ file here:
>> (use /Tp with VC++ and -xc++ with gcc and you are done).
>>
>> Is this still true with modules?
>> That is: Can we expect that identifying a file as C++ file is enough to be
>> able to (pre) compile it as C++ file?
>>
>> Current compilers give different answers (AFAIK):
>>
>> - *gcc *says the same suffix is possible. There is not special option for
>> modules.
>> I can still have my own suffixes and use -xc++ though.
>>
>> - *VC++* currently requires different suffixes or different command-line
>> arguments.
>> Identifying a file as C++ file is not enough.
>> For example
>> - This is not enough: /Tp mymod.cppm
>> - You need: /interface /Tp mymod.cppm
>>
>> I wonder whether the behavior of VC++ is standard conforming.
>>
>> I see no place in the C++ standard saying that there has to be different
>> treatment of C++ source files to make them work.
>> Or do we require this somewhere?
>> We do not require different treatment just because we have templates,
>> namespaces, or exceptions used inside.
>> Therefore, I would expect that also using modules does not require special
>> handling.
>> (This is independent from the question whether different suffixes help to
>> deal with these files).
>>
>> If I am right, VC++ is not standard conforming.
>>
>>
>> In any case it would help a lot to clarify:
>> Can all C++ source files expect that treating them the same way works fine?
>>
>> If not, we obviously need different suffixes. But then we should clearly say
>> so (without necessarily saying which suffix it is).
>>
>>
>> I hope this questions brings us a bit forward to be able teach the first
>> *portable *"hello, modules" example.
>>
>> Thanks
>>
>> Nico
>>
>> --
>> ---
>> Nicolai M. Josuttis
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rGQUFYPVGC6vH5MaGf4q6GG%2BB8fTzeWGtqy%2BSjZ9w30%3D&reserved=0
>> +49 (0)531 / 129 88 86
>> +49 (0)700 / JOSUTTIS
>>
>> Books:
>> C++:https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd20.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3RK5Al6NSQ9aaLx4mj7IAYuvW2IBRAD292Q5A3%2BlZAk%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd17.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6HM1W8MPFGlu1AeYoBJHI9IeRXS7VmxTw5w8YTn8FD4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppmove.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N%2BKcVW0jDyb9rEFMBB1r69HTdjAP%2BJa4STQPn3vs7Z8%3D&reserved=0,
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oHQRsZCq6VomTGLKM9tyotrYPxwh3ZocNgZaBeqgOo4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftmplbook.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gVVlDFg7ZDl5T%2Bgcbyf5KrwiqLBOEFfLbSR19DGDMgQ%3D&reserved=0
>>
>> --
>> Nico Josuttis
>> (sent from my mobile phone)
>>
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WuvKKYX%2FnkV6rIOADi4dtNc3IUcjURRipoLglLkOHHw%3D&reserved=0
>
>
>--
>Nathan Sidwell
>_______________________________________________
>Ext mailing list
>Ext_at_[hidden]
>Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FKzU3Gsik%2F2SAyJOOmZfJ%2FWTRZ8jjpc4cXaOotkWrB0%3D&reserved=0
>Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19021.php&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DjZPo5RuyycaIgn8Yp3q%2BX2kmXv4Oj9lTHkPIsyYk4Q%3D&reserved=0
>_______________________________________________
>Ext mailing list
>Ext_at_[hidden]
>Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
>Link to this post: http://lists.isocpp.org/ext/2022/04/19023.php
I REALLY would like to have the first portable "hello module" example.
Currently, there is simply no way to have it. That's really a shame.
Am 15. April 2022 20:46:59 MESZ schrieb Gabriel Dos Reis via Ext <ext_at_[hidden]>:
>Nathan - you recount is all correct.
>
>> I know I've mentioned it more than once, but I find it unsettling, given there
>> was great opposition to there being a (two way?) mapping between file names and
>> module names, that there is a move in the direction of making file names
>> 'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>> alice.$MODULESUFFIX is taking us all the way back to the first objection above
>> about having two languages.
>
>I am not seeing any movement to make filename suffixes significant in the linguistic interpretation, by the compiler, of the content of source file. Maybe I am not looking right; but I would definitely recommend against such move. There are extra linguistic considerations that might force a toolset (not just a compiler) to require certain suffixes, but those suffixes do not determine the meaning a C++ program -- this is not different from compilers like GCC or MSVC refusing to compile in default mode files ending with ".h" or similar because they generally have other connotations.
>
>For some reasons, the topic of the "right" suffix seems to generate more passion than the topic of what can we do with modules, so maybe we are already doing a lot with modules 😝
>
>-- Gaby
>
>-----Original Message-----
>From: Ext <ext-bounces_at_[hidden]> On Behalf Of Nathan Sidwell via Ext
>Sent: Friday, April 15, 2022 11:21 AM
>To: sg15_at_[hidden]; ext_at_[hidden]; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>Cc: Nathan Sidwell <nathan_at_[hidden]>
>Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?
>
>On 4/13/22 17:10, Nico Josuttis via SG15 wrote:
>> I should add that the fact that we need
>> module;
>> at the beginning of the global module fragment was only introduced to let a file
>> identify itself as module file.
>> If we would require different suffixes, that would not have been necessary.
>>
>> But correct me if I am wrong.
>
>I shall correct you :)
>
>Here's the history (as I recall, all persons mentioned are real, and not to be
>confused with ficticious characters)
>
>* prior to me doing things with gcc, there was only 'module FOO;' as a module
>declaration at-most once within a TU. MSVC (the only compiler with module
>smarts at the time), had a flag to tell it 'this is an interface' vs 'this is an
>implementation'.
>
>* I found this unsatisfying, as it meant that there was something outside the
>source tokens that told you how to interpret them. In effect we had two languages.
>
>* IIRC, Gaby, Jason (Merrill) and I came up with the 'export module FOO;' vs
>'module foo;' distinction. But still this could be anywhere in the source
>stream. I was able to implement this functionality to a working system.
>
>* Daveed proposed an early signifier of 'hey, this is gonna be a module', should
>the actual module declaration not be first. Hence 'module;' was born. (My
>understanding was that this was driven by implementors, as they had difficulty
>entering a module-like mode not at start of compilation, and indeed it was a
>little tricky to do that. I do not know if this was also a user request.)
>
>* post p1103, the requirement that everything between 'module;' and the module
>decl come from #include came to be.
>
>Hope that helps.
>
>I know I've mentioned it more than once, but I find it unsettling, given there
>was great opposition to there being a (two way?) mapping between file names and
>module names, that there is a move in the direction of making file names
>'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>alice.$MODULESUFFIX is taking us all the way back to the first objection above
>about having two languages.
>
>nathan
>
>>
>>
>>
>> Am 13. April 2022 22:58:13 MESZ schrieb Nicolai Josuttis via Ext
>> <ext_at_[hidden]>:
>>
>> What I teach about modules is compelling. Programmers like and want to use it.
>> However, they ask how they should organize module files in practice.
>>
>> So far I cannot recommend a specific suffix (and I might never be able to do
>> that).
>> However there is one important question that IMO the standard should answer:
>> *Do we **/need /**different suffixes?*
>>
>> I understand that a suffix discussion is only of practical value.
>> But IMO the standard has to give an answer here (which has nothing to do
>> with which suffixes are used).
>>
>> Let me elaborate that in detail:
>>
>> Not having a standard suffix has interesting consequences.
>> So far we have header files and translation units.
>> But once we know what a C++ translation unit is, we can just compile them
>> all with the same compiler options or commands. Because in practice we have
>> different suffixes for header and source files, we can set-up generic rules
>> to compile our code.
>>
>> This works for any suffix, provided you know the way to tell the compiler
>> that we have a C++ file here:
>> (use /Tp with VC++ and -xc++ with gcc and you are done).
>>
>> Is this still true with modules?
>> That is: Can we expect that identifying a file as C++ file is enough to be
>> able to (pre) compile it as C++ file?
>>
>> Current compilers give different answers (AFAIK):
>>
>> - *gcc *says the same suffix is possible. There is not special option for
>> modules.
>> I can still have my own suffixes and use -xc++ though.
>>
>> - *VC++* currently requires different suffixes or different command-line
>> arguments.
>> Identifying a file as C++ file is not enough.
>> For example
>> - This is not enough: /Tp mymod.cppm
>> - You need: /interface /Tp mymod.cppm
>>
>> I wonder whether the behavior of VC++ is standard conforming.
>>
>> I see no place in the C++ standard saying that there has to be different
>> treatment of C++ source files to make them work.
>> Or do we require this somewhere?
>> We do not require different treatment just because we have templates,
>> namespaces, or exceptions used inside.
>> Therefore, I would expect that also using modules does not require special
>> handling.
>> (This is independent from the question whether different suffixes help to
>> deal with these files).
>>
>> If I am right, VC++ is not standard conforming.
>>
>>
>> In any case it would help a lot to clarify:
>> Can all C++ source files expect that treating them the same way works fine?
>>
>> If not, we obviously need different suffixes. But then we should clearly say
>> so (without necessarily saying which suffix it is).
>>
>>
>> I hope this questions brings us a bit forward to be able teach the first
>> *portable *"hello, modules" example.
>>
>> Thanks
>>
>> Nico
>>
>> --
>> ---
>> Nicolai M. Josuttis
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rGQUFYPVGC6vH5MaGf4q6GG%2BB8fTzeWGtqy%2BSjZ9w30%3D&reserved=0
>> +49 (0)531 / 129 88 86
>> +49 (0)700 / JOSUTTIS
>>
>> Books:
>> C++:https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd20.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3RK5Al6NSQ9aaLx4mj7IAYuvW2IBRAD292Q5A3%2BlZAk%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd17.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6HM1W8MPFGlu1AeYoBJHI9IeRXS7VmxTw5w8YTn8FD4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppmove.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N%2BKcVW0jDyb9rEFMBB1r69HTdjAP%2BJa4STQPn3vs7Z8%3D&reserved=0,
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oHQRsZCq6VomTGLKM9tyotrYPxwh3ZocNgZaBeqgOo4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftmplbook.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gVVlDFg7ZDl5T%2Bgcbyf5KrwiqLBOEFfLbSR19DGDMgQ%3D&reserved=0
>>
>> --
>> Nico Josuttis
>> (sent from my mobile phone)
>>
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WuvKKYX%2FnkV6rIOADi4dtNc3IUcjURRipoLglLkOHHw%3D&reserved=0
>
>
>--
>Nathan Sidwell
>_______________________________________________
>Ext mailing list
>Ext_at_[hidden]
>Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FKzU3Gsik%2F2SAyJOOmZfJ%2FWTRZ8jjpc4cXaOotkWrB0%3D&reserved=0
>Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19021.php&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DjZPo5RuyycaIgn8Yp3q%2BX2kmXv4Oj9lTHkPIsyYk4Q%3D&reserved=0
>_______________________________________________
>Ext mailing list
>Ext_at_[hidden]
>Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
>Link to this post: http://lists.isocpp.org/ext/2022/04/19023.php
-- Nico Josuttis (sent from my mobile phone)
Received on 2022-04-15 19:05:13