On 4 December 2017 at 21:29, Allan Sandfeld Jensen <k...@carewolf.com> wrote: >> > I believe the name "optional" comes from Haskell and Java where it >> > appeared >> > first. The standard library only imports things that are already industry >> > standard, and once there were several implementations of optional out >> > there, they started to pull one in. They just didn't manage to write it >> > without using C++17'isms. >> >> std::optional has no fundamental c++17isms in it, and can be written >> without any problem in C++11 code. >> I maintain optional in libstdc++, in case you wonder on what basis I'm >> making that statement. > I know it can be written with C++11. I have both seen it, and done it myself. > I was just noting the C++17 version takes advantage of C++17 (which makes > sense). I did not mean to imply you couldn't or hadn't. I am sorry if I > formulated that wrongly.
Right; stylistically, the C++17 specification uses C++17 facilities when convenient - that has nothing to do with what the committee "manages" to do or not. For optional, it uses, for example, the _v trait-value variable templates, which are C++17, but are perfectly possible to express with the longer-hand form with ::value. Beyond those, optional doesn't do anything C++17-specific (and was in fact implemented *and specified* in terms of C++14 when it was experimental::optional, and even there, the only C++14 facility it used was relaxed constexpr, but again, those things can be written with C++11 constexpr). Under the general as-if rule, implementations can and do implement optional with equivalent facilities that were there since well before C++17. >> The standard library imports a whole host of things that aren't always >> industry standards. but it imports things only when there's a proposal >> to import something. > > For this part I was refering call for proposals http://cplusplus.github.io/ > LWG/call-for-library-proposals.html which says it strongly prefers things > based on existing practice. Yes, *prefers*, but doesn't *require*. Even the ISO guideline of standardizing existing practice is a recommendation, not a hard requirement. > Anyway. I was just taking offense at Marc's claims that Qt was "stealing from > C++" by adopting similar compatible ideas as the standard library, but made > available for our supported platforms in our time frame. It made little sense > to me, as you might as well argue Qt is stealing from Windows and Mac, by > making a cross-platform toolkit implementing their established practices. I think Marc's concern is adopting e.g. an optional-like type and giving it a *completely* different interface because we prefer camelNames to std_like_names, which is migration-wise, generic-programming-wise and interoperability-wise a complete dead end. This leads to a discussion we need to have at some point, which is that if we write a Qt facility that's expected (no expected-related puns intended) to have an equivalent facility in the standard, we should give such facilities a standard-like interface with standard-like naming, instead of following our usual naming conventions. Same goes for semantics. Which brings us back to the discussion on constexpr on QStringView - it hurts migration and interoperability if string_view has constexpr operations that are not constexpr on QStringView. Having said that, there are nuances there, like *how much* it hurts and what kind of migration/interoperability. General design principles can have engineering exceptions, when the rationale for such is sufficient. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
