I just posted my ISO C++ meeting trip report over on isocpp.org covering our meeting in Urbana-Champaign earlier this month.
The ISO C++ committee is shipping more work sooner via concurrent Technical Specifications, but it’s still fairly new to find ourselves doing so much work that the “new normal” is to issue an international ballot from every ISO C++ meeting. This time, we have four ballots coming out of this meeting — the first (of two) ballots for the Transactional Memory TS, the final ballots for the Library Fundamentals TS and the Parallelism TS, and a new work item for C++17 since this was the first meeting of the C++17 era.
Oh, and we had evening sessions. Did I mention evening sessions? Five nights’ worth.
Now, two weeks later, I’m almost caught up on sleep.
Almost.
But what a blast. I’m looking forward to the next few smaller meetings over the winter, and the next full one in May.
Sutter’s Mill 
For the explicit return stuff the concerns have weight. Why don’t we just move strictly forward with a form like
return auto {1,2 3};
?
For me that looks covering most of the motivations while not breaking or changing anything already out there.
@Nolange: The File System TS is in its final ballot, which closes on Monday (Dec 1). You can always see the latest progression status on https://isocpp.org/std/status — see the embedded Excel spreadsheet, and page 2 of the spreadsheet includes the current ballot stage information.
True, using string_view will save time and space but even for string_view I didn’t see a split() function that has alrady been implemented or in the TODO list of either GCC or Clang. BTW, why is it that string objects must have to own it’s own copy? Couldn’t we share the memory between strings and make string objects range objects? I am not that experienced on how the internals are implemented but it is technically possible isn’t it? I’ve used string.assign a lot in that respect. Thanks for all your effort, appreciate it!
Hello Herb,
I wonder whats with the filesystem TS? It seems to be “quite ready” for an awful lot of time, but there aint any news on this for almost the same amount of time.
On string_view, I remember how you had (have?) to explicitly copy substrings in Java, as otherwise you end up with keeping references on the potential huge string. If this proposal wont do something similar, then you still need the option to easily create smaller, independent strings and free the big instance
Just to bring up another string-related itch…is there any chance of getting case-insensitive string functionality into the standard library in C++17?
It’s kind of embarrassing when someone new to C++ asks how to do it, and I have to get into traits specialization and/or downloading Boost.
@Madura A.: I agree we should have a way to split strings, but — surprise — you usually don’t really want to actually physically split strings into multiple string objects. Watch
[w]string_view, which is like an ‘iterator range’ on someone else’s string storage… a lot of us are working on that and its cousinarray_view. My view is thatstring_viewis almost certain to grow those kinds of functions. And doing it onstring_viewwill be way more efficient than actually physically splitting a string, which would require actually copying characters and most of the time you don’t need to do that, you just want to know where the substrings start and end and read them, which is most efficient when you do it in-place without copying the storage.Herb, what about N3593? I love the work you guys are doing on the new standards but C++’s standard libary sometimes forces developers to rebuild functions that are simple as split() (for strings). What are your ideas on this and why do you think N3593 haven’t been implemented yet on modern runtimes?
@GregM: The concern was that it might still be a pitfall in a large function and especially under maintenance, see for example N4094. I don’t share the concerns (and others besides Bjarne and I were still supportive of the proposal), but my main motivation was returning tuples and so as long as we fix tuple’s constructors to not be explicit all the time so that I can easily use those as return types with the return statement syntax “return { x, y, z };”, I didn’t think it was worth spending more time and effort trying to convince the committee of this more general convenience syntax. Who knows, sometimes old proposals come back in the future… but I have no plans to bring it back, and if it ever does come back it would have to address the objections somehow either by a technical change to the proposal or by more persuasive technical arguments for the previous proposal.
Herb, can you talk about why your proposal for return allowing explicit constructors was controversial?