<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-text-flowed" style="font-family: -moz-fixed;
      font-size: 14px;" lang="x-unicode">Hi,
      <br>
      <br>
      I was happly ignoring the other threads, since I didn't like the
      temperature of some the responses.
      <br>
      <br>
      But I guess you force me to write a response not just to you, but
      something that is a bit more general.
      <br>
      <blockquote type="cite" style="color: #000000;">Or... just don't
        do that?
        <br>
        <br>
        I can't recall that I've <b class="moz-txt-star"><span
            class="moz-txt-tag">*</span>ever<span class="moz-txt-tag">*</span></b>
        had problems with QObject ownership.
        <br>
      </blockquote>
      <br>
      You, and a few others have made similar arguments, that start from
      your personal experience and since you do not needed something
      conclude that it is not worth doing.
      <br>
      <br>
      And please don't read the rest of the mail as a attack on you,
      that's not intended. I think it's important to hear from all kind
      of different users, but I need to point out what I perceive as a
      faulty argument.
      <br>
      <br>
      It is imho the wrong perspective:
      <br>
      <br>
      There's a wide spectrum of Qt users.
      <br>
      * Some of which don't want Qt to change [much].
      <br>
      * Some of which want leverage new C++ features while using Qt
      <br>
      * Some of which want Qt to be more like the C++ standard
      <br>
      <br>
      By arguing from a personal standpoint, you are implicitly ignoring
      all users that aren't like you. A proposal (or the rejection)
      should be based on considering the effect not just on you, but on
      all kind of different users.
      <br>
      <br>
      Except, just considering current users, would be quite wrong.
      <br>
      <br>
      Qt needs to continously attract new users, as it otherwise dies
      with the current user base. Those users will mostly - I would
      assume - come from a C++ backgroud. And my experience as a
      freelancer is that most projects I see use at least C++11 and I
      have no trouble finding projects using more modern standards.
      <br>
      <br>
      But even that, would be the wrong perspective. We are discussing
      APIs in the context of Qt 6, which will be around for a decade.
      Thus, the correct perspective would be to consider which kind of
      user Qt wants to attract and serve in a few years. And I believe
      that in a few years, most people with a C++ background would
      expect modern apis.
      <br>
      <br>
      The same perspective error happens from these arguing for
      deprecation and removal, too.
      <br>
      <br>
      For example, obviously Q_FOREACH is ugly and outdated. It seems
      some argue that the benefit of not having to teach Q_FOREACH is
      worth the major pain and frustration that existing users would
      experience if it just got removed. I can't understand that.
      <br>
      <br>
      In fact the whole premise of the thread is imho misguided. If the
      goal is making Qt and C++ more interoperable, then deprecation and
      removal is the wrong way to go about it.
      <br>
      <br>
      The way forward should be to create win-win situations for both
      those that want to make use of modern C++ and those that are quite
      happy with Qt as it is.
      <br>
      <br>
      For example, I wish Qt 6 would:
      <br>
      <br>
      * enable templated QObjects. There's a prototype from Olivier, so
      is that possible?
      <br>
      * support move only types in Qt container
      <br>
      * add overloads for all functions taking bool * that make use of
      std::optional
      <br>
      * add overloads for all functions using output parameters. auto
      [...] = foo() is imho ugly, but that's nevertheless better than
      output parameters
      <br>
      * have great interoprability with ranges
      <br>
      <br>
      None of that would require making Qt worse for existing users.
      <br>
      <br>
      <blockquote type="cite" style="color: #000000;">Generally, if you
        follow three rules:
        <br>
        <br>
        - If you create an object on the stack, either don't parent it
        or ensure
        <br>
        its parent outlives it. (Usually not hard!)
        <br>
        - If you create an object with `new`, **create** it with a
        parent.
        <br>
        - Otherwise use a smart pointer (QScopedPointer or
        QSharedPointer)ยน.
        <br>
        <br>
        ...you just won't have problems.
        <br>
      </blockquote>
      <br>
      And that doesn't need to change with my design at all. You can
      just write the same code as is. To reiterate a point that seems to
      be a source of misunderstanding, in the design I proposed the vast
      majority of objects are never owned by a unique_ptr. Most objects
      are created with a parent.
      <br>
      <br>
      And there are small benefits that even those that don't want to
      use unique_ptr, can get with minimal effort. For example by using
      the new makeChild function:
      <br>
      <br>
      parent->makeChild(...);
      <br>
      <br>
      It's almost impossible to forget to pass a parent parameter. And
      best of all, no one is forced to use that, but it can be adopted
      at whatever pace is best.
      <br>
      <br>
      And for your last case of holding a QObject in a smart pointer,
      the propsal makes that drastically less akward.
      <br>
      <br>
      So, I think what I have actually proposed has zero costs to those
      that don't want to use it, while enabling those that e.g. want to
      make use of tooling around memory managment capable of doing so.
      <br>
      <br>
      daniel
      <br>
      <br>
    </div>
  </body>
</html>