On Wed, 14 Jul 2021 at 04:56, Jason Merrill <ja...@redhat.com> wrote: > > On 7/12/21 3:58 PM, Jonathan Wakely wrote: > > On Mon, 5 Jul 2021 at 20:07, Jason Merrill <ja...@redhat.com> wrote: > >> > >> On 6/26/21 10:23 AM, Andrew Sutton wrote: > >>> > >>> I ended up taking over this work from Jeff (CC'd on his existing email > >>> address). I scraped all the contracts changes into one big patch > >>> against master. See attached. The ChangeLog.contracts files list the > >>> sum of changes for the patch, not the full history of the work. > >> > >> Jonathan, can you advise where the library support should go? > >> > >> In N4820 <contract> was part of the language-support clause, which makes > >> sense, but it uses string_view, which brings in a lot of the rest of the > >> library. Did LWG talk about this when contracts went in? How are > >> freestanding implementations expected to support contracts? > > > > I don't recall that being discussed, but I think I was in another room > > for much of the contracts review. > > > > If necessary we could make the std::char_traits<char> specialization > > available freestanding, without the primary template (or the other > > specializations). But since C++20 std::string_view also depends on > > quite a lot of ranges, which depends on iterators, which is not > > freestanding. Some of those dependencies were added more recently than > > contracts was reviewed and then yanked out, so maybe wasn't considered > > a big problem back then. In any case, depending on std::string_view > > (even without the rest of std::basic_string_view) is not currently > > possible for freestanding. > > I guess I'll change string_view to const char* for now.
I think that's best. Making std::string_view usable would take some work. > >> I imagine the header should be <experimental/contract> for now. > > > > Agreed. > > And the type std::experimental::??::contract_violation. Maybe > contracts_v1 for the inline namespace? LGTM > Did you have any thoughts about the violation handler? Is it OK to add > a default definition to the library, in the above namespace? I'd rather not have any std::experimental::* symbols go into the DSO. For std::experimental::filesystem we added libstdc++fs.a, with no corresponding .so library, which users need to link to explicitly to use that TS. Would something like libstdc++contracts.a work here? Is it just one symbol? Aside: Ulrich Drepper suggested recently that the driver should have been updated to automatically add -lstdc++fs so that using <experimental/filesystem> was seamless, as the archive contents wouldn't be used unless something in the program referred to the symbols in it. Is just using std::terminate as the handler viable? Or if we're sure contracts in some form will go into the IS eventually, and the signature won't change, we could just add it in __cxxabiv1:: as you suggested earlier.
