On Sat, 8 Apr 2023 at 07:07, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Friday, 7 April 2023 14:14:29 -03 Jan Schultke via Std-Proposals wrote:
> > Namely it improves performance because it can help with devirtualization:
> > x.fun1().fun2().fun3()
>
> Do we need to change the syntax for declaring what those functions return
> or
> do we need a way to make the statement above more efficient? The case of
> operator++ doesn't really matter here because they're almost never virtual
> and
> they're almost always inline in the first place. Though I do note that
> it's not
> necessary for it to be virtual for this to be useful.
>
> So what if instead we fixed the call chain above, or had a simpler syntax
> to
> reuse the same object? Such as:
>
> x.(fun1(), fun2(), fun3());
>
> Maybe even make it statement-like:
> x.{
> fun1();
> if (fun2())
> fun3();
> };
>

Perhaps an abuse of lambda syntax would work?

[this = &x]{
     fun1();
     if (fun2())
         fun3();
}();

This would in turn allow each of those functions to return something other
> than this and be useful in other scenarios. For example,
> QString::replace()
> returns QString & (a *this reference) so you could write:
>
> qsizetype n = str.replace("foo", "bar").replace("\\",
> "\\\\").indexOf("xyz");
>
> But if we had had a syntax for call-chaining of the same object,
> QString::replace() would probably have returned the number of replacements
> made, which is a far more useful result when you're *not* chaining.
>
> And if changing the call syntax is not a possibility, this does sound like
> a
> good use of an attribute:
>
> [[returns_this]] QString &replace(const QString &a, const QString &b);
>
> [[returns_this]] Derived *f() override;
>
> That would allow an update of existing uses without ABI breaks, does not
> introduce a new syntax, and does permit the optimisations discussed by
> declaring that it's UB to return something other than *this (like
> returning
> from a [[noreturn]] function). The drawback is that it adds to what one
> must
> type, but I find it arguable that the proposed, shorter syntax is actually
> *better* by suppressing the return statement.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>