Important: Please read the Qt Code of Conduct -

Proposal: useful return values instead of void

  • Hi, I don't know if it's the right group to make proposals about the API, but I think it would be useful to have some functions return something instead of void. For example, the various setXxxx() methods could return "this" instead of void.
    Consider this example:
    QLabel *l = new QLabel("...", this);
    ... other set functions
    Now consider if every function returned a "this" pointer:
    layout->addWidget((new QLabel("...", this))->setBuddy(...)->setWordWrap(...)->ecc ecc);
    Much more compact, and no temporary variable.
    As a general principle, this could apply to many other kind of functions too.

    Bye and thanks for all
    Michele Alessandrini

    Edit: please use @ tags around code sections; Andre

  • Moderators

    Monads, monads everywhere :) I like this kind of "this" returning, but, as you rightly suspect, this is not the right place to propose API changes. You need to send this to "Development": mailing list.

    What you are proposing, though, is too big a change to be included in any Qt5 release. I would have to wait (probably several years) for Qt6. And that only if you round up many people in your support. And best if you submit patches yourself, too :)

  • Hi, thank for your reply!
    I did not suspect that there would exist BOTH forums and mailing lists :-) And "development" confused me because you are always a developer when using Qt :-)
    I realize that's a big change, and maybe too vague, and maybe touching every single Qt source file! But actually in this case it would not be "noticed" by code calling the void-type functions, cause they already ignore the returned value.
    Anyway, just launching some hints...

  • Returning a reference to the instance after every method member call that doesn't need to return a useful value to allow chaining is not that bad of an idea.

    Nonetheless I doubt this will be incorporated regardless of where you take your proposal.

  • I don't really see the benefits here. Sure you can cram up more information in a single line, but when (since program memory isn't an issue anymore) has this ever been a good idea? Code should be untangled and laid out clearly, not compressed. If you want to compress, C++ gives you all the power, just write
    and enjoy perl-like unreadability.

  • I like the idea, it is more close to a "natural" language.
    @DerManu: you can still use the old style even if "this" is returned. :)

  • If the functions return a pointer you get this mixed syntax when using a stack based object:
    Object w;
    w.doStuff()->doMoreStuff()-> ...;

    and if the function returns a reference you get this mixed syntax when using heap objects:
    Object *w;
    w->doStuff().doMoreStuff(). ...;

    Personally I think I prefer the consistency and clarity of:
    Object w;
    w. ...;
    // or
    Object *w;
    w-> ...;

  • There is a nice document that came out of research Trolltech did back when they made Qt.
    The research is about how to write useful APIs.
    One of the main things is "code will be read more often then it is written, so write for readability".
    I think this suggestion would make code much less readable, it would be easy to miss that one 'set' being doing on a long line of setters.
    The book is "The Little Manual of API design". You might find it floating around the internernet somewhere since the original location seems to have gone blank...

  • Moderators

    Qt slots need to return void, no? QLabel::setText() is a slot, so it can't be made to return `this' (unless slot requires are changed in the future)

    [quote author="m.alessandrini" date="1360267667"]But actually in this case it would not be "noticed" by code calling the void-type functions, cause they already ignore the returned value.[/quote]True, the change is source-compatible. But, it's not binary-compatible ( ), so the change can't be done in Qt 5.

    Nonetheless, thanks for sharing your suggestion! If you're passionate about this issue, bring up the discussion again when Qt 6 is approaching, and we'll see where we stand then :)

  • Moderators

    Qt slots are just standard c++ methods, they can return anything. Signals should be declared with void return.

  • Thanks for sharing the "The Little Manual of API Design" link.
    I got a felling that I'm going to enjoy it reading very much. I was not aware of that manual.


  • I don't think this proposal has much chance of getting through. As ChrisW67 illustrated, it will result in weird looking code either way you implement it, and compressing code on single lines isn't stimulated either.

    However, I sometimes would like to have some references available to avoid stuff like this:
    QFont f = myLabel->font();

    It would be nice to be able to write:

    and have that actually change the font for the label. However, I guess there are problems there of how the label is supposed to know about any changes made in such cases.

  • Moderators

    Does not necessary need to be compressed to a single line:

    I actually use this concept in my "QEasyShell": but for a slightly different reasons (to make code look more shell-like).

  • There should always the concept of void, it sometimes relax a "new to programming person's" mind. Anyhow suggestion is great for experts.

  • [quote author="sierdzio" date="1360318574"]Does not necessary need to be compressed to a single line:

    Well that kind of beats the purpose, right? Writing a space/tab instead of a "w". His goal was to compress more code into one line, which is horrible API design as has been pointed out a few times.

    is much easier searchable, replaceable, regexable, reorderable and finally readable than your version, in my opinion.

    [quote]to make code look more shell-like.[/quote]
    so... to make code feel less intuitive in order to give the feeling of using 40 year old unix CLI syntax? Noble goals... ;)
    Just kidding, QEasyShell looks cool. And that's actually a good point to mention. This idiom of returning a this pointer to allow such lines of code with much information content is great for scripting languages, e.g. shell scripts. But C++ isn't a scripting language and programs tend to have more than 1 kloc. So while scripting languages can and should give the developer the freedom to pump out enormous functionality in shortest times, languages intended for large scale development should actually limit the developers in many respects, to make them think about their code and lay out the logic of the program very clearly.

  • Hi, thank you very much to everybody for your interesting comments.

    I know this was a very vague idea, but I'd like to point out that "weird" or "unreadable" code is much a subjective idea, and I think that an API itself is not responsible for how the code will be written, but it should better give users maximum freedom on how to work. For example, I personally find a code much more readable if I can read a whole functional block of code in a single screen without having to scroll.


  • Actually Qt already uses such fluent interfaces in spots, like QString (<code>QString(...).remove(...).append(...)</code>) or QDataStream.

    I see the benefits of having the possibility of method chaining, and this should be proposed for Qt6 (so it will be at least discussed).

    RIM already provides a (or some kind of) fluent interface in a binary compatible way for their Cascades Framework (which is based on Qt) using their Builder concept (as for example in "Cascades::Sheet":

  • Yeah, but Qt6 is a long time away. Also, wouldn't that add a (minimal) performance penalty? And last but not least, judging by the declarative direction of Qt, there will hardly be anything to chain. With QML or any other markup being used to set properties in a declarative way, this whole endeavor seems (almost entirely) redundant.

  • Binary incompatible changes, as for instance changing the return value, aren't allowed within a major release. So this would have to go in Qt6 no matter what.

    There is indeed a minuscle performance penalty, which is however irrelevant in practice compared to the work in a non-trivial setter.

    Yes, this does not affect QtQuick, but this doesn't mean that QtWidgets couldn't or shouldn't be improved.

  • Honestly, I'd be surprised if widgets are still alive in Qt6 timeframe. Maybe in some form similar to the Qt3 compatibility module in Qt4.

  • [quote author="utcenter" date="1360623465"]Honestly, I'd be surprised if widgets are still alive in Qt6 timeframe.[/quote]If that happens, I will personally fork Qt and invite everybody to continue with a Framework for proper applications. Everybody else may use QML for their thirty-thousandth flickable photo album app and tetris clone.

  • I hope widgets are will be still alive in Qt6, if not come up something better than QML.
    It's like FDD was alive until flash drives not come up, and CD or CD-RW is not able to replace the FDD.

  • There is too much of a code base to support, so I doubt widgets will be removed altogether, but consider that Qt6 might very well be 5+ years away. It took almost 8 years from Qt4 to Qt5. Widgets will probably look as awkward as Qt3 widgets today.

    Despite the current lack of initiative, I honestly expect that Qt5 will actually see a new, better, more flexible and lighter C++ API to substitute widgets, which are stiff and centered around a fixed UI paradigm that fits less and less into the world of today.

  • I am agree with you that UI paradigm what we have today is played-out and we need something lighter and convenient. But for today i don't see the alternatives.

  • As someone that earns his bread doing Qt work, I can tell you that QtQuick is being used for 'real' applications. With good success too.
    The thing that catches many by surprise is that the applications that used to be 'real' stopped being the main group of apps. I'm talking about those applications that people use in the office. From Word/Excel to hours-management apps. But also apps like used by stores, marketing etc etc.
    Those serious apps are still there, but the rest of the apps are growing much faster due to availability of speciality hardware. And QML is perfectly suited for the majority of 'real' apps.

    Sorry for the incoherent explanation, I hope it may at least give one person a "oh, I understand" feeling ;)

Log in to reply