[Development] QtCS 2017 QtCore sessions

[Ville Voutilainen]

On 4 December 2017 at 21:29, Allan Sandfeld Jensen <kde at 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.