[SUGGESTION] Implement the pipeline operator from P2011 & P2672 #741

bluetarpmedia · 2023-10-10T00:35:19Z

Suggestion
Cpp2 could support the pipeline operator |> as proposed in P2011 and further explored in P2672.

Specifically, the pipeline operator with the "placeholder model" with mandatory placeholder (e.g. $), as described in P2672 section 6 Disposition. Both papers explain the problem and motivation for the new operator, as well as discussing options for the placeholder token.

Circle uses $ as its token.

The proposed operator enables a simpler left-to-right style as opposed to an inside-out style.

Conor Hoekstra (code_report) has various talks about ranges and pipelines and explains how the pipeline operator can make the code simpler and more readable. The following is one of his examples:

Without the operator:

auto filter_out_html_tags(std::string_view sv) {
    auto angle_bracket_mask = 
        sv | rv::transform([](auto e) { return e == '<' or e == '>'; });
    return rv::zip(rv::zip_with(std::logical_or{}, 
            angle_bracket_mask, 
            angle_bracket_mask | rv::partial_sum(std::not_equal_to{})), sv)
        | rv::filter([](auto t) { return not std::get<0>(t); })
        | rv::transform([](auto t) { return std::get<1>(t); })
        | ranges::to<std::string>;
}

With the operator:

auto filter_out_html_tags(std::string_view sv) {
    return sv 
        |> transform($, [](auto e) { return e == '<' or e == '>'; })
        |> zip_transform(std::logical_or{}, $, scan_left($, true, std::not_equal_to{}))
        |> zip($, sv)
        |> filter($, [](auto t) { return not std::get<0>(t); })
        |> values($)
        |> ranges::to<std::string>($);
}

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?
No

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?
No

Describe alternatives you've considered.
Alternatives are discussed at length in the two papers referenced above.

The text was updated successfully, but these errors were encountered:

JohelEGP · 2023-10-10T00:42:46Z

~~The talk: "New Algorithms in C++23 - Conor Hoekstra - C++ on Sea 2023".~~
The recommended version: "Guide to the New Algorithms in C++23 - Conor Hoekstra - CppNorth 2023".

hsutter · 2023-10-10T01:08:01Z

The proposed operator enables a simpler left-to-right style as opposed to an inside-out style.

As soon as I see this, I think "hmm, like UFCS does?", and then I saw the example which looks suspiciously like UFCS for most of the cases.

Clarifying questions, just so I understand the question (I haven't had time to watch the talk).

Is the $ is the placeholder for where to put the left-hand side of the operator, so that this code (ignoring for now the zip_transform one where it's not in the first location):

    return sv 
        |> transform($, [](auto e) { return e == '<' or e == '>'; })
        |> zip($, sv)
        |> filter($, [](auto t) { return not std::get<0>(t); })
        |> values($)
        |> ranges::to<std::string>($);

would be the same as this using UFCS, which I think would work in Cpp2 now:

    return sv 
        .transform(:(e) e == '<' || e == '>';)
        .zip(sv)
        .filter(:(t) !std::get<0>(t);)
        .values()
        .ranges::to<std::string>();

or something like that, modulo any late-night typos I wrote?

JohelEGP · 2023-10-10T01:11:20Z

That's right.

Including zip_transform, I have confirmed that this translates correctly (https://cpp2.godbolt.org/z/7Wdbf5o1Y, https://compiler-explorer.com/z/hcx9ex4j4 [formatted]):

#include <algorithm>
#include <ranges>
using namespace std::views;
// auto filter_out_html_tags(std::string_view sv) {
//     return sv 
//         |> transform($, [](auto e) { return e == '<' or e == '>'; })
//         |> zip_transform(std::logical_or{}, $, scan_left($, true, std::not_equal_to{}))
//         |> zip($, sv)
//         |> filter($, [](auto t) { return not std::get<0>(t); })
//         |> values($)
//         |> ranges::to<std::string>($);
// }
filter_out_html_tags_cpp2: (sv: std::string_view) -> _ = {
  (a := sv
        .transform(:(e) e == '<' || e == '>';))
  return zip_transform(std::logical_or(), a, scan_left(a, true, std::not_equal_to()))
        .zip(sv)
        .filter(:(t) !std::get<0>(t);)
        .values()
        .to<std::string>();
}
main: () = { }

Can you remind me where scan_left comes from?

bluetarpmedia · 2023-10-10T01:13:54Z

Can you remind me where scan_left comes from?

scan_left is from code_report's example.

auto scan_left(auto rng, auto init, auto op) {
    return transform(rng, [first = true, acc = init, op](auto e) mutable {
            if (first) first = false; 
            else acc = op(acc, e);
            return acc;
        });
}

hsutter · 2023-10-10T01:14:07Z

Wow, that was fast. I was just trying to write the code for zip_transform a different way, but I see a statement parameter worked.

What about expressing this

    |> zip_transform(std::logical_or{}, $, scan_left($, true, std::not_equal_to{}))

as this

    . :(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to())) ()

?

Then it's all . ?

(I haven't tried to compile the code though.)

bluetarpmedia · 2023-10-10T01:16:10Z

There's some overlap between UFCS and this proposed pipeline operator.

Conor's presentation shows off various range pipeline examples, but the P2011 and P2672 papers discuss the motivation and problem space.

P2011 also discusses how it's different to UFCS. I think the key difference for Cpp2 is allowing the placeholder to appear in different argument positions in order to compose the range algorithms and views.

JohelEGP · 2023-10-10T01:26:15Z

Do you have a test?
This compiles: https://cpp2.godbolt.org/z/n8673xofn.

I had to add to, because Libstdc++ doesn't have ranges::to.
Also, Libc++ doesn't implement zip_transform.
(https://en.cppreference.com/w/cpp/compiler_support).

JohelEGP · 2023-10-10T01:31:23Z

By the way, I just took the parameter of to by in.
The error message was hideous.
I compiled locally with #506 (and some other things)
and quickly found out

x.cpp2:4:104: error: no match for call to ‘(to<std::__cxx11::basic_string<char>, std::ranges::elements_view<…

(… inserted by me).
These are the sizes of the error outputs:

$ ls out-* -lh
-rw-r--r-- 1 johel johel 60K Oct  9 21:28 out-main
-rw-r--r-- 1 johel johel 23K Oct  9 21:27 out-waarudo

JohelEGP · 2023-10-10T01:34:47Z

Do you have a test?

I added one.
It seems to output characters rather than strings.
https://cpp2.godbolt.org/z/s5crPezaj.

JohelEGP · 2023-10-10T01:36:04Z

. :(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to())) ()

That's not valid grammar (https://cpp2.godbolt.org/z/9avjYh6sb):

main.cpp2...
main.cpp2(25,10): error: '.' must be followed by a valid member name (at '(')

hsutter · 2023-10-10T01:37:52Z

Yes -- in a racing update I was updating the comment to say the following, but I'll make it a separate reply instead:

Right, that code is currently rejected because . must be followed by a name.
So perhaps have a general helper like call:(f) :(x) f(x); to enable writing

    .call(:(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to()));)

modulo typos and bugs? Or maybe name it curry? Anyway, signing off for tonight, but a very interesting question! Thanks.

bluetarpmedia · 2023-10-10T01:43:05Z

You're right that UFCS is very close already, and arguably the dot syntax is just as nice as the new operator, but with UFCS I'd still prefer a token to make the syntax simpler. (Perhaps _ is better than Circle's choice of $ since there's already precedent in Cpp2.)

.zip_transform(std::logical_or{}, _, scan_left(_, true, std::not_equal_to{}))

JohelEGP · 2023-10-10T01:51:34Z

Excellent.
It works again with call:(forward o, forward f) f(o); (https://cpp2.godbolt.org/z/evj8PnzE7).
Circle:

auto filter_out_html_tags(std::string_view sv) {
    return sv 
        |> transform($, [](auto e) { return e == '<' or e == '>'; })
        |> zip_transform(std::logical_or{}, $, scan_left($, true, std::not_equal_to{}))
        |> zip($, sv)
        |> filter($, [](auto t) { return not std::get<0>(t); })
        |> values($)
        |> ranges::to<std::string>($);
}

Cpp2 (colored):

Text

filter_out_html_tags_cpp2: (sv: std::string_view) //
  sv.transform(:(e) e == '<' || e == '>')
    .call(:(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to())))
    .zip(sv)
    .filter(:(t) !t.get<0>())
    .values()
    .to<std::string>();

JohelEGP · 2023-10-10T01:53:25Z

IIRC, that proposal has seen push back
due to having to specify the semantics
of pipe arguments as non-first argument and
of multiple pipe arguments in the same function call.

AbhinavK00 · 2023-10-10T02:58:47Z

Since there's talk about P2672, is there any interest for placeholder lambdas to replace the recently added :(x) x syntax?

JohelEGP · 2023-10-11T14:29:50Z

You're right that UFCS is very close already, and arguably the dot syntax is just as nice as the new operator, but with UFCS I'd still prefer a token to make the syntax simpler. (Perhaps _ is better than Circle's choice of $ since there's already precedent in Cpp2.)

.zip_transform(std::logical_or{}, _, scan_left(_, true, std::not_equal_to{}))

Standalone $, specially as an argument, has no meaning in Cpp2.
It could mean "capture the object argument here" in a function call expression.
And so the default becomes today's "capture the object argument as the first argument".
"Object argument" means the expression before the ..

So when you write x.f(args),
you get the default for x.f($, args).
UFCS is then defined to apply when the first argument is $.

We still have the problem of having to specify the behavior when
the object argument appears more than once or
it appears as more than a simple $, e.g., $.first.

Anyways, I think a simple $ argument plays well with
https://github.com/hsutter/cppfront/wiki/Design-note%3A-Capture and
https://github.com/hsutter/cppfront/wiki/Design-note%3A-Defaults-are-one-way-to-say-the-same-thing.

JohelEGP · 2023-10-11T16:34:16Z

Do you have a test?

I added one.
It seems to output characters rather than strings.
https://cpp2.godbolt.org/z/s5crPezaj.

Looks like it works on characters, indeed.
Using the fixed implementation from #741 (comment), https://cpp2.godbolt.org/z/qjvonb8s3,
it prints the same as the CE link from the talk at codereport/Content: https://godbolt.org/z/on5xMG5ax.

JohelEGP · 2023-10-11T19:24:14Z

@codereport FYI.

The code in this comment should now parse correctly: #741 (comment)

hsutter · 2023-10-12T00:21:26Z

I wish I could use the terse function syntax, but main.cpp2: error: unexpected end of source file.

Thanks! It's rare these days that I find a bug in the very first "load" step that tags which code is Cpp1 vs Cpp2, but this was one. I think it's fixed in this commit: 789cd38

is there any interest for placeholder lambdas to replace the recently added :(x) x syntax?

Do you mean like Boost.Lambda's _1 + f() ? If so...

My concern with that is, would it be:

Would it be a special feature that works only in anonymous function bodies?
Would it be allowing a second way to say the same thing (not just defaulting) -- a competing syntax to teach, and one that meets overlapping needs so we would have to teach which to use when? Whereas the current syntax for lambdas is still a single syntax with optional parts you can omit when you're not using them.

I could be persuaded to like _1-style placeholders, though, if these two things could be addressed:

If they could serve a general purpose in the language beyond anonymous function placeholder parameters, just like $ for capture works for "capture value" semantics everywhere (not just in anonymous function captures, but also postconditions and string interpolation).
If that general use were allowed in ordinary named functions in a way that still naturally lets us omit unused parts of the general function syntax to get down to anonymous functions, so we still have a single function syntax.

Does that make sense?

hsutter · 2023-10-12T00:27:01Z

I don't seem to have a C++ compiler installed on this machine that supports all of the new range/view things used in this example, because I'm mainly testing with a-few-years-old compilers to ensure compatibility.

But if I understand correctly, the original example of this:

auto filter_out_html_tags(std::string_view sv) {
    auto angle_bracket_mask = 
        sv | rv::transform([](auto e) { return e == '<' or e == '>'; });
    return rv::zip(rv::zip_with(std::logical_or{}, 
            angle_bracket_mask, 
            angle_bracket_mask | rv::partial_sum(std::not_equal_to{})), sv)
        | rv::filter([](auto t) { return not std::get<0>(t); })
        | rv::transform([](auto t) { return std::get<1>(t); })
        | ranges::to<std::string>;
}

which could be written more simply using the proposed |> operator like this:

auto filter_out_html_tags(std::string_view sv) {
    return sv 
        |> transform($, [](auto e) { return e == '<' or e == '>'; })
        |> zip_transform(std::logical_or{}, $, scan_left($, true, std::not_equal_to{}))
        |> zip($, sv)
        |> filter($, [](auto t) { return not std::get<0>(t); })
        |> values($)
        |> ranges::to<std::string>($);
}

works in Cpp2/cppfront today using just UFCS like this (with a helper call:(forward o, forward f) f(o);):

filter_out_html_tags_cpp2: (sv: std::string_view) -> _ = {
    return sv
        .transform(:(e) e == '<' || e == '>';)
        .call(:(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to()));)
        .zip(sv)
        .filter(:(t) !t.get<0>();)
        .values()
        .to<std::string>();
}

... Is that correct?

JohelEGP · 2023-10-12T00:29:51Z

That's right.

I wish I could use the terse function syntax, but main.cpp2: error: unexpected end of source file.

Thanks! It's rare these days that I find a bug in the very first "load" step that tags which code is Cpp1 vs Cpp2, but this was one. I think it's fixed in this commit: 789cd38

Yes, this works now.

filter_out_html_tags_cpp2: (sv: std::string_view) //
  sv.transform(:(e) e == '<' || e == '>';)
    .call(:(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to()));)
    .zip(sv)
    .filter(:(t) !t.get<0>();)
    .values()
    .to<std::string>();

hsutter · 2023-10-12T00:42:02Z

[Edited to add that this also helps reduce need for library techniques like overloading |]

Groovy, thanks.

I've learned two major things from this thread:

UFCS is even more useful than I thought. It isn't just good for enabling generic code (to be able to call functions whether they're members or nonmembers, which today we can only do with operators) and good for enabling IDEs (autocomplete), but it can help reduce the pressure to add special-purpose language features like |> and reduce pressure to use special-purpose library techniques like overloading |.
The brand-new very terse syntax has surprised me with how immediately useful it has been, including in this thread. It's a smallish change that really feels game-changing, because it shortens just enough of the ceremony of declaring the anonymous function so that it goes from feeling like "an ordinary function that has this expression body" to "an ordinary expression that we use as a function just by prefixing :(x)" (both are valid, but the latter feels powerful to me somehow).

JohelEGP · 2023-10-12T01:00:45Z

Opened #746 for this.
Something I've mentioned before is that UFCS on a qualified name doesn't work with GCC: https://compiler-explorer.com/z/qb19TEGv1.
And Cpp2 doesn't have using declarations: #559.
So we'd have to put using ranges::to at global scope, outside any namespace, possibly far from its use.
I can do that now that I realized that the ranges::to in the code was range-v3's and not std's.
But maybe it's just a GCC bug.

AbhinavK00 · 2023-10-12T05:01:06Z

I wish I could use the terse function syntax, but main.cpp2: error: unexpected end of source file.

Thanks! It's rare these days that I find a bug in the very first "load" step that tags which code is Cpp1 vs Cpp2, but this was one. I think it's fixed in this commit: 789cd38

is there any interest for placeholder lambdas to replace the recently added :(x) x syntax?

Do you mean like Boost.Lambda's _1 + f() ? If so...

My concern with that is, would it be:

Would it be a special feature that works only in anonymous function bodies?

Would it be allowing a second way to say the same thing (not just defaulting) -- a competing syntax to teach, and one that meets overlapping needs so we would have to teach which to use when? Whereas the current syntax for lambdas is still a single syntax with optional parts you can omit when you're not using them.

I could be persuaded to like _1-style placeholders, though, if these two things could be addressed:

If they could serve a general purpose in the language beyond anonymous function placeholder parameters, just like $ for capture works for "capture value" semantics everywhere (not just in anonymous function captures, but also postconditions and string interpolation).

If that general use were allowed in ordinary named functions in a way that still naturally lets us omit unused parts of the general function syntax to get down to anonymous functions, so we still have a single function syntax.

Does that make sense?

Well, my thinking was that the current new syntax was already kind of divergent. Yes, it is obtained by omitting parts but that ommitance is conflicting (omitting -> Type means void return type while omitting -> _ = means deduced return type.) Furthermore, this syntax would make it's way to full (named) function declarations where it's desirable for full parts to be present. That conflicts with your 2nd point but that's how I see it. Most languages which have a short lambda syntax do not allow omitting from full functions.
As for the more general presence of placeholders, if the pipeline operator is present, that'd be one place for them in the language but I got nothing on this front. Maybe some places in the language can be tweaked for this (like its done with string interpolation, it easily could've been done with format library but $ was used because it was present more generally in cpp2).
It'll not be competing because it'd only work for anonymous functions, maybe there's no need to start the with :.

JohelEGP · 2023-10-12T05:03:31Z

Well, my thinking was that the current new syntax was already kind of divergent. Yes, it is obtained by omitting parts but that ommitance is conflicting (omitting -> Type means void return type while omitting -> _ = means deduced return type.)

That's because when you're using the terse syntax,
the default you're writing for is -> _ =.
See https://github.com/hsutter/cppfront/wiki/Design-note%3A-Defaults-are-one-way-to-say-the-same-thing.

To me, allowing a generic function f:(i:_) -> _ = { return i+1; } to be spelled f:(i) i+1; is like that... there's only one way to spell it, but you get to omit parts where you're happy with the defaults.

JohelEGP · 2023-10-18T19:44:38Z

Optional Placeholder

Let's consider the placeholder is optional.

If we don't pass it keyword as an argument in UFCS, this is implicitly the first argument.

Also it keyword can be generalized to refer to the left operand of a binary operation. For example:

var1: = (x + y) * (x + y);
// It's the same as above. `it` is `(x + y)`.
var2: = (x + y) * it;

// The first  `it` is `(x + y)`.
// The second `it` is `(x + y) * it`.
var3: = (x + y) * it * it;

var4: = ab.fnc1(it, it).fnc2(it, it);
var5: = ab.fnc1(ab).fnc2(ab.fnc1(ab));

And we can change the position of this argument in UFCS. In this example, this object is the last argument:

//  : = fnc1(arg, obj);
var1: = obj.fnc1(arg, it);

This feature improves chained UFCS without requiring to use additional helper function call and lambda expression. Considering the example from the proposal, it will be changed with UFCS and it keyword in Cpp2:

filter_out_html_tags_cpp2: (sv: std::string_view)
  sv.transform(: (e) e == '<' || e == '>')
//  .call(:(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to()));)
    .zip_transform(std::logical_or(), it, scan_left(it, true, std::not_equal_to()))
    .zip(sv)
    .filter(: (t) ! t.get<0>())
    .values()
    .to<std::string>();

If it's hard to find it keyword (although an editor with syntax highlighting can help in this case), another syntax such as $$ may be used.

The point of the placeholder is that:

It allows us to explicitly specify the position of this argument in UFCS.
It can be used to refer to the left operand of any binary operation too.
It doesn't require additional helper function call and lambda expression.

So I'm in favor of @bluetarpmedia's comment (but in a way that placeholder is optional):

You're right that UFCS is very close already, and arguably the dot syntax is just as nice as the new operator, but with UFCS I'd still prefer a token to make the syntax simpler. (Perhaps _ is better than Circle's choice of $ since there's already precedent in Cpp2.)

.zip_transform(std::logical_or{}, _, scan_left(_, true, std::not_equal_to{}))

msadeqhe · 2023-11-15T09:22:53Z

In another words, the placeholder is optional. If it keyword (or any other notation) is passed as an argument in UFCS, this argument will be passed in place of it:

var1: = ab.fnc1(mn, it);
//  : =    fnc1(mn, ab);

Otherwise this argument will be implicitly the first argument:

var1: = ab.fnc1(mn);
//  : =    fnc1(ab, mn);

So we can have chained function calls regardless of whether this is the first parameter or not.

msadeqhe · 2023-11-15T10:36:25Z

Optional Placeholder Syntax

If you find optional placeholders not to be readable, its readability may be increased by adding extra this like if it was a keyword argument (it depends on what will be the syntax of keyword arguments or designated constructors):

//  : = obj.fnc1(this: = x, it);
//  : = obj.fnc1(this? x, it);
var1: = obj.fnc1(this x, it);

Briefly A.F(this B, it) is equal to B.F(A) which it falls back to F(B, A). That's it.

Without this, we cannot write it keyword in argument list:

var1: = obj.fnc1(x, it); // ERROR! `it` keyword requires explicit `this` argument.

And without it, UFCS will work as how we currently use it:

var1: = obj.fnc1(x); // OK. It falls back to `fnc1(obj, x)`.

The example from the proposal will be like this (with new syntax):

filter_out_html_tags_cpp2: (sv: std::string_view)
  sv.transform(: (e) e == '<' || e == '>')
//  .call(:(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to()));)
    .zip_transform(this? std::logical_or(), it, scan_left(it, true, std::not_equal_to()))
    .zip(sv)
    .filter(: (t) ! t.get<0>())
    .values()
    .to<std::string>();

So optional placeholder doesn't conflict with the way UFCS works today, it complements it. Thanks.

SebastianTroy · 2023-11-15T10:55:34Z

Suggestion to use 'lhs' instead of 'it' as keyword for this proposal. It is clearer as to the meaning of the value, and I found myself substituting 'it' for 'left hand side' in my head whenever I read it On 15 November 2023 10:36:41 Sadeq ***@***.***> wrote: Optional Placeholder Syntax If you find optional placeholders not to be readable, it may increase readability by adding extra this like if it was a keyword argument (it depends on what will be the syntax of keyword arguments or designated constructors): // : = obj.fnc1(this: = x, it); // : = obj.fnc1(this? x, it); var1: = obj.fnc1(this x, it); Briefly A.F(this B, it) is equal to B.F(A) which it falls back to F(B, A). That's it. Thanks. Without this, we cannot write it keyword in argument list: var1: = obj.fnc1(x, it); // ERROR! `it` keyword requires explicit `this` argument. And without it, UFCS will work as how we currently use it: var1: = obj.fnc1(x); // OK. It falls back to `fnc1(obj, x)`. So the placeholder doesn't conflict with the way UFCS works today, it complements it. — Reply to this email directly, view it on GitHub<#741 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQMNOYQDBIQY5TWNEDTYESLLLAVCNFSM6AAAAAA5ZQQZ32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGIYTGNRQGI>. You are receiving this because you commented.Message ID: ***@***.***>

JohelEGP · 2023-11-25T19:55:33Z

. :(x) zip_transform(std::logical_or(), x, scan_left(x, true, std::not_equal_to())) ()

That's not valid grammar (https://cpp2.godbolt.org/z/9avjYh6sb):

Right, I like the call helper well enough that I'm waiting to see if there's really a need to write a new function expression in the middle of a postfix-expression... it's doable but is it needed?

You could say it's needed for #748,
so we could write w: (f) :(x) x.(f$)();
and have x.(f$)() call (f$)(x).

There is another use case.
In a member function of a type template,
UFCS on a dependent base member requires explicit qualification (https://cpp2.godbolt.org/z/Mff1G9331):

u: @struct <T> type = {
  f: (_) true;
}

t: @struct <T> type = {
  this: u<T>;

  operator(): (this, r: std::span<const int>) -> _ = {
    for r do (e) {
      // OK.
      return this.f(e);

      // error: explicit qualification required to use member 'f' from dependent base class
      //   16 |       return CPP2_UFCS_0(f, e); 
      //      |                          ^
      return e.f();

      // error: expected unqualified-id
      //   21 |       return CPP2_UFCS_0(f, e.(*this)); 
      //      |                               ^
      return e.this.f();

      // OK.
      return e.u<T>::f();

      // What I would like to write:
      // return e.(this.f)();
      //  That translates to this:
      return (this.f)(e);
    }
  }
}

main: () = {
  r: std::vector = (0, 1, 2);
  assert(t<int>()(r));
}

JohelEGP · 2023-11-25T20:10:18Z

From #748 (comment):

Also, can't do UFCS on a dependent base member (#741 (comment)):

For now, I can workaround this with using u<T>::f;, which makes return e.f(); well-formed: https://cpp2.godbolt.org/z/T5b5sxbYr.

From #748 (comment):

Function object prvalue

I forgot to mention this other case where you first need to construct a callable.

Consider the call in the assert in the main above: t<int>()(r).
t<int>() is the function object we want to call.

Let's rewrite it in UFCS order: r.t<int>()().
The function to call becomes t<int> instead.
The second () applies to the result of the UFCS.

The call helper does help:
r.call(t<int>()) (https://cpp2.godbolt.org/z/Mfc5TP8xz).

The code in this comment should now parse correctly: hsutter#741 (comment)

See comment thread for previous commit: 4bd0c04

DerpMcDerp · 2024-02-12T03:03:36Z

The unary pipeline operator can be used for terse lambda syntax, i.e. |> foo($0, $2) == :(x, _, z) foo(x, z);

* Add `..` syntax to select a member function only With this commit, `x.f()` is still UFCS, but `x..f()` will now find only a member function. For now I like that the default is UFCS, but as we get more experience I'm open to changing the default so that `.` is member selection and `..` is UFCS (which would be a breaking change, but a mechanical one). Also: Remove the old version of `get_declaration_of` now that the new lookup seems stable. * Remove some debug code * Finish removing old g_d_o paths

bluetarpmedia added the suggestion label Oct 10, 2023

hsutter added a commit that referenced this issue Oct 12, 2023

Fixed terse syntax bug reported in #741 comments

789cd38

The code in this comment should now parse correctly: #741 (comment)

JohelEGP mentioned this issue Oct 12, 2023

[BUG] [GCC] UFCS with qualified function fails #746

Closed

JohelEGP mentioned this issue Nov 11, 2023

[BUG] No direct UFCS syntax for (captured function object, dependent base member, function object prvalue) #748

Open

JohelEGP mentioned this issue Nov 25, 2023

Const by default #815

Open

zaucy pushed a commit to zaucy/cppfront that referenced this issue Dec 5, 2023

Fixed terse syntax bug reported in hsutter#741 comments

bf278b7

The code in this comment should now parse correctly: hsutter#741 (comment)

JohelEGP referenced this issue Dec 7, 2023

Emit anonymous functions as constexpr or mutable lambdas

b9e73e0

See comment thread for previous commit: 4bd0c04

JohelEGP mentioned this issue Mar 1, 2024

[SUGGESTION] Ability to disable UFCS both via cppfront and for regions in source code #1004

Closed

[SUGGESTION] Implement the pipeline operator from P2011 & P2672 #741

[SUGGESTION] Implement the pipeline operator from P2011 & P2672 #741

Comments

bluetarpmedia commented Oct 10, 2023

JohelEGP commented Oct 10, 2023 • edited Loading

hsutter commented Oct 10, 2023 • edited Loading

JohelEGP commented Oct 10, 2023 • edited Loading

bluetarpmedia commented Oct 10, 2023

hsutter commented Oct 10, 2023 • edited Loading

bluetarpmedia commented Oct 10, 2023

JohelEGP commented Oct 10, 2023

JohelEGP commented Oct 10, 2023

JohelEGP commented Oct 10, 2023

JohelEGP commented Oct 10, 2023 • edited Loading

hsutter commented Oct 10, 2023 • edited Loading

bluetarpmedia commented Oct 10, 2023

JohelEGP commented Oct 10, 2023 • edited Loading

JohelEGP commented Oct 10, 2023 • edited Loading

AbhinavK00 commented Oct 10, 2023

JohelEGP commented Oct 11, 2023

JohelEGP commented Oct 11, 2023

JohelEGP commented Oct 11, 2023

hsutter commented Oct 12, 2023

hsutter commented Oct 12, 2023 • edited Loading

JohelEGP commented Oct 12, 2023 • edited Loading

hsutter commented Oct 12, 2023 • edited Loading

JohelEGP commented Oct 12, 2023 • edited Loading

AbhinavK00 commented Oct 12, 2023

JohelEGP commented Oct 12, 2023 • edited Loading

JohelEGP commented Oct 18, 2023

JohelEGP commented Oct 18, 2023

gregmarr commented Oct 18, 2023

hsutter commented Oct 20, 2023 • edited Loading

JohelEGP commented Nov 11, 2023

SebastianTroy commented Nov 11, 2023 via email

JohelEGP commented Nov 11, 2023

JohelEGP commented Nov 11, 2023

MaxSagebaum commented Nov 13, 2023

msadeqhe commented Nov 15, 2023 • edited Loading

Optional Placeholder

msadeqhe commented Nov 15, 2023 • edited Loading

msadeqhe commented Nov 15, 2023 • edited Loading

Optional Placeholder Syntax

SebastianTroy commented Nov 15, 2023 via email

JohelEGP commented Nov 25, 2023 • edited Loading

JohelEGP commented Nov 25, 2023 • edited Loading

DerpMcDerp commented Feb 12, 2024

JohelEGP commented Oct 10, 2023 •

edited

Loading

hsutter commented Oct 10, 2023 •

edited

Loading

JohelEGP commented Oct 10, 2023 •

edited

Loading

hsutter commented Oct 10, 2023 •

edited

Loading

JohelEGP commented Oct 10, 2023 •

edited

Loading

hsutter commented Oct 10, 2023 •

edited

Loading

JohelEGP commented Oct 10, 2023 •

edited

Loading

JohelEGP commented Oct 10, 2023 •

edited

Loading

hsutter commented Oct 12, 2023 •

edited

Loading

JohelEGP commented Oct 12, 2023 •

edited

Loading

hsutter commented Oct 12, 2023 •

edited

Loading

JohelEGP commented Oct 12, 2023 •

edited

Loading

JohelEGP commented Oct 12, 2023 •

edited

Loading

hsutter commented Oct 20, 2023 •

edited

Loading

msadeqhe commented Nov 15, 2023 •

edited

Loading

msadeqhe commented Nov 15, 2023 •

edited

Loading

msadeqhe commented Nov 15, 2023 •

edited

Loading

JohelEGP commented Nov 25, 2023 •

edited

Loading

JohelEGP commented Nov 25, 2023 •

edited

Loading