UFCS with multiple related arguments #811

msadeqhe · 2023-11-08T06:51:53Z

msadeqhe
Nov 8, 2023

UFCS is really expressive when we want to constrcut an object from one argument:

person: type = {
    // ...
    operator=: (out this, name: std::string) = { /* ... */ }
    // ...
}

var1: = "Alex".person();
//  : person = "Alex";

Also it's nice to convert or manipulate objects with constructors:

var2: = "Hello World!".std::string(5);
//  : = "Hello";

And it looks like UDL suffixes and supports multiple units too:

var3: = 10.box().apple();

But when we construct an object from multiple related arguments, it significantly harms readability:

var4: = 0.point(0, 0, true);
var5: = "Alex".person(30, country::usa);

Would it be possible to extend UFCS to support multiple arguments on the left side?

var4: = (0, 0, 0).point(true);
var5: = ("Alex", 30, country::usa).person();

It increases readability and helpfully allows us to separate related arguments to the left side of operator..

I opened two issues (#455, #463) to request this feature before, but mistakenly my suggestions contained syntax changes.

The syntax doesn't really matter, only a way to put related arguments aside is enough. Thanks.

msadeqhe · 2023-11-08T08:47:54Z

msadeqhe
Nov 8, 2023
Author

But when we construct an object from multiple related arguments, it significantly harms readability:
var4: = 0.point(0, 0, true);
var5: = "Alex".person(30, country::usa);
Would it be possible to extend UFCS to support multiple arguments on the left side?
var4: = (0, 0, 0).point(true);
var5: = ("Alex", 30, country::usa).person();
It increases readability and helpfully allows us to separate related arguments to the left side of operator..

I know it conflicts with comma operator in Cpp1, but it can work without any problem in Cpp2.

0 replies

SebastianTroy · 2023-11-08T09:05:28Z

SebastianTroy
Nov 8, 2023

var4: = (0, 0, 0).point(true); var5: = ("Alex", 30, country::usa).person(); At this point, why is this better than var4: = point(0, 0, 0, true); var5: = person("Alex", 30, country::usa); I don't dislike your proposal per-se, I just want to understand why you think we can increase readability by arbitrarily splitting up arguments between before and after the function /typename Also I understand that ufcs allows for certain templates to become more generic, does this proposal help this at all? On 8 November 2023 06:52:10 Sadeq ***@***.***> wrote: UFCS is really expressive when we want to constrcut an object from one argument: person: type = { // ... operator=: (out this, name: std::string) = { /* ... */ } // ... } var1: = "Alex".person(); // : person = "Alex"; Also it's nice to manipulate objects with constructors: var2: = "Hello World!".std::string(5); And it looks similar to UDL suffixes that supports multiple units: var3: = 10.box().apple(); But when we want to construct an object from multiple arguments, it significantly harms readability: var4: = 0.point(0, 0, true); var5: = "Alex".person(30, country::usa); Would it be possible to extend UFCS to support multiple arguments? var4: = (0, 0, 0).point(true); var5: = ("Alex", 30, country::usa).person(); It would helpfully allow us to separate related arguments to the left side of operator.. I opened two issues (#455<#455>, #463<#463>) to request this feature before, but mistakenly my suggestions contained syntax changes. The syntax doesn't really matter, only a way to put related arguments aside is enough. Thanks. — Reply to this email directly, view it on GitHub<#811>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQP2VNVJQZFRCDJVXTLYDMTZNAVCNFSM6AAAAAA7CLSMF6VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVHAZDMMZTGY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

2 replies

msadeqhe Nov 8, 2023
Author

I don't dislike your proposal per-se, I just want to understand why you think we can increase readability by arbitrarily splitting up arguments between before and after the function /typename

According to P3021r0 paper from @hsutter, UFCS has the following benefits:

3.1.1. It’s friendlier to editors and tools
3.1.2. It’s friendlier to programmers: Discoverability
3.1.3. It more directly corresponds to what programs do: State transition
3.1.4. The existing-practice workarounds already simulate extending the member call syntax, not the nonmember syntax

If I want to construct a 3D point, and | is the cursor in the following example:

var1: = (0, 0, 0).|

The editor will show me the appropriate list of functions and types (3.1.1). The editor will find types and functions which can be called with those parameters, and it will show me a list of them. In this example, it may show me a list with point, matrix, etc.

Also as Herb wrote in that paper (3.1.2):

This illustrates why the member call syntax is generally friendlier to programmers. I believe the “start with the
object” point of view is a much more usable programming model because it directly enables answering the con-
stant question of how to discover “what can I do next?”. What you can do next (functions) depends on what you
have now to do it with (your objects and variables).

In this example, our object has 3 parts (0, 0, 0) instead of 1 part "Alex".

And another important case is state transition (3.1.3), I as a programmer prefer to write the object and then I do something to that. In this example, our object has 3 parts (0, 0, 0).

And for the last case (3.1.4):

(first(), second()).third();

third(first(), second());

Infact, my suggestion is motiviated from Herb's P3021r0 paper that makes me think why we still need UFCS with multiple related arguments.

Also I understand that ufcs allows for certain templates to become more generic, does this proposal help this at all?

I mean, the only thing that matters in my suggestion is readability and toolability, and it works in generic programming too (because of UFCS):

fnc1: (a: i32, b: i32, c: bool) = { /* ... */ }

(0, 0).fnc1(true);

So (0, 0).fnc1(true) calls non-member functions too. The separated arguments would make it clear that what was the intention of the programmer in generic programming. So yes, it helps in generic programming too. Thanks.

msadeqhe Nov 8, 2023
Author

I think generally member function call is preferred over non-member function call, because member function call is UFCS in Cpp2, so UFCS can be used for every function call including functions/constructors with multiple related arguments (such as (0, 0, 0)).

If I use non-member function call syntax just in case I want to construct an object with multiple related arguments, I will lose the benefits of UFCS. For example if I use:

var4: = point(0, 0, 0, true);
var5: = person("Alex", 30, country::usa);

I will lose the benefits of UFCS in generic programming in addition to decreasing readability and toolability.

SebastianTroy · 2023-11-08T11:36:00Z

SebastianTroy
Nov 8, 2023

Oh I'm already well in favour of UFCS, and I agree that your multiple arguments allows for nicer discovery of types pertaining to the variables, but what programmer intent is portrayed when viewing (a, b).f(c); Vs a.f(b, c); Autocomplete is already the work of a tool, so extending it to work with "(a, b, c)." doesn't necessarily require a language feature, as it could easily auto complete to "type(a, b, c)" Basically my point is, do we need to visually complicate the language further, when the feature you suggest is for a tool rather than the language? On 8 November 2023 10:21:10 Sadeq ***@***.***> wrote: I don't dislike your proposal per-se, I just want to understand why you think we can increase readability by arbitrarily splitting up arguments between before and after the function /typename According to P3021r0 paper from @hsutter<https://github.com/hsutter>, UFCS has the following benefits: 3.1.1. It’s friendlier to editors and tools 3.1.2. It’s friendlier to programmers: Discoverability 3.1.3. It more directly corresponds to what programs do: State transition 3.1.4. The existing-practice workarounds already simulate extending the member call syntax, not the nonmember syntax If I want to construct a 3D point, and | is the cursor in the following example: var1: = (0, 0, 0).| The editor will show me the appropriate list of functions and types (3.1.1). The editor will find types and functions which can be called with those parameters, and it will show me a list of them. In this example, it may show me a list with point, matrix, etc. Also as Herb wrote in that paper (3.1.2): This illustrates why the member call syntax is generally friendlier to programmers. I believe the “start with the object” point of view is a much more usable programming model because it directly enables answering the con- stant question of how to discover “what can I do next?”. What you can do next (functions) depends on what you have now to do it with (your objects and variables). In this example, our object has 3 parts (0, 0, 0) instead of 1 part "Alex". And the most important case in my example is state transition (3.1.3), I as a programmer prefer to write the object and then I do something to that. And for the last case (3.1.4): (first(), second()).third(); third(first(), second()); Infact, my suggestion is motiviated from Herb's P3021r0 paper that makes me think why we still need UFCS with multiple related arguments. Also I understand that ufcs allows for certain templates to become more generic, does this proposal help this at all? I mean, the only thing that matters in my suggestion is readability and toolability, and it works in generic programming too (because of UFCS): fnc1: (a: i32, b: i32, c: bool) = { /* ... */ } (0, 0).fnc1(true); So (0, 0).fnc1(true) calls non-member functions too. The separated arguments would make it clear that what was the indention of the programmer in generic programming. So yes, it helps in generic programming too. Thanks. — Reply to this email directly, view it on GitHub<#811 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQIBJFQSMJPKQRJ47Y3YDNMJHAVCNFSM6AAAAAA7CLSMF6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMBYGYYTO>. You are receiving this because you commented.Message ID: ***@***.***>

2 replies

msadeqhe Nov 8, 2023
Author

You're right. My suggestion is visually useful for constructors only. I think more about it, if I don't find a useful feature from this syntax, I will close this discussion. Thanks.

msadeqhe Nov 9, 2023
Author

Autocomplete is already the work of a tool, so extending it to work with "(a, b, c)." doesn't necessarily require a language feature, as it could easily auto complete to "type(a, b, c)"

Replace type with function in function(a, b, c) and we lose UFCS in generic programming, so it will never call member functions. Therefore a language feature is required to have (a, b, c).function().

In addition to readability and toolability, I'm thinking about use cases and why (a, b, c).function() would help us to write short/nice code.

JohelEGP · 2023-11-08T13:21:48Z

JohelEGP
Nov 8, 2023

I think this might encourage writing inside-out code again.
Consider slide 127 of https://github.com/codereport/Content/blob/main/Talks/2023-07-CppNorth/New%20Algorithms%20in%20C%2B%2B23/New%20Algorithms%20in%20C%2B%2B23.pdf.

auto sushi_for_two(std::vector<int> sushi) { // clang-format off
  return sushi
      |> zip_with(_neq_, $, $ | drop(1))
      |> zip($, iota(1))
      |> filter($, _fst)
      |> values($)
      |> concat(single(0), $, single(sushi.size()))
      |> zip_with(_sub_, $ | drop(1), $)
      |> zip_with(_min_, $, $ | drop(1))
      |> std::ranges::max($) * 2;
} // clang-format on

Line |> concat(single(0), $, single(sushi.size())) has the input object as the second argument.
That's .call(:(x) concat(single(0), x, sushi.size().single()))
with the call from #741 (comment).
With multiple-argument UFCS, it would be possible to break the linearity of the code from

sushi_for_two: (sushi: std::span<int>) //
  sushi                                //
    .call(:(x) zip_with(_neq_, x, x.drop(1)))
    .zip(iota(1))
    .filter(_fst)
    .values()
    .call(:(x) concat(single(0), x, sushi.size().single()))
    .call(:(x) zip_with(_sub_, x.drop(1), x))
    .call(:(x) zip_with(_min_, x, x.drop(1)))
    .std::ranges::max() *
  2;

to

sushi_for_two: (sushi: std::span<int>) //
  (single(0), sushi                    //
                .call(:(x) zip_with(_neq_, x, x.drop(1)))
                .zip(iota(1))
                .filter(_fst)
                .values())
    .concat(sushi.size().single())
    .call(:(x) zip_with(_sub_, x.drop(1), x))
    .call(:(x) zip_with(_min_, x, x.drop(1)))
    .std::ranges::max() *
  2;

2 replies

msadeqhe Nov 9, 2023
Author

Thanks. If we could declare variable within parentheses, it would be like this:

sushi_for_two: (sushi: std::span<int>) (
    _min_,
    a: = (
        _sub_,
        (b: = (
            single(0),
            (_neq_, c: = sushi, c.drop(1))
             .zip_with()
             .zip(iota(1))
             .filter(_fst)
             .values(),
            sushi
             .size()
             .single()
        ).concat()).drop(1),
        b
    ).zip_with(),
    a.drop(1)
).zip_with()
 .std::ranges::max() * 2;

EDIT: But there is a difference, in my example it doesn't use lambdas. It directly calls the functions.

msadeqhe Nov 9, 2023
Author

If Cpp2 had keyword value, prev or it to refer to the value of the left operand of operator., the example would be changed to:

sushi_for_two: (sushi: std::span<int>)
  sushi
    .zip_with(_neq_, it, it.drop(1))
    .zip(iota(1))
    .filter(_fst)
    .values()
    .concat(single(0), it, sushi.size().single())
    .zip_with(_sub_, it.drop(1), it)
    .zip_with(_min_, it, it.drop(1))
    .std::ranges::max() * 2;

With keyword value, prev or it, we don't have to use lambdas, we can directly use UFCS.

Also it would be helpful in every expression too. it means the left operand in everywhere:

a: = 10;

var1: = (a * a + 2) * it / 2;

// The above line is equal to the following lines:
xx: = a * a + 2;
var2: = xx * xx / 2;

EDIT: But unfortunately it doesn't work with nested operator. in UFCS:

x: = a.b(c, m.d(it));

it in m.d(it) doesn't refer to a, instead it refers to m.

EDIT: I've removed all the parts which was about reflections and solving the nested operator. problem. It wasn't a correct solution. sry.

msadeqhe · 2023-11-09T08:34:03Z

msadeqhe
Nov 9, 2023
Author

Briefly, I suggest to make ...

(obj, a1, a2, ...).call(b1, b2, ...)

... a syntax sugar to ...

obj.call(a1, a2, ..., b1, b2, ...)

Therefore if call is a type, it would call the constructor without this argument, otherwise it would call a non-member function:

TYPE(/* out this */, obj, a1, a2, ..., b1, b2, ...)
FUNCTION(obj, a1, a2, ..., b1, b2, ...)

But if call is a member function of obj, it would call it with obj as this argument, otherwise it would call a non-member funcion:

obj.FUNCTION(a1, a2, ..., b1, b2, ...)
FUNCTION(obj, a1, a2, ..., b1, b2, ...)

So the behavior of it depends on if call is a type or a member funcion.

As you see, (obj, a1, a2, ...).call(b1, b2, ...) is more readable when call is a type, because obj is similar to a1, a2, ... arguments. But when call is a function, it may be misleading, because obj is alongside a1, a2, ... arguments while they are different.

So if we use UFCS, we can argue that (a, b, c).call() is the right way to call constructors to create objects, and a.call(b, c) is the right way to call functions. In generic programming, both of these syntaxes are helpful. Because I as a programmer want to create an object, and if my code works as intended with a member function or non-member function too, also I would be happy.

On the other hand, if for readability reasons I change x.point(y, z) to point(x, y, z), I lose the power of UFCS in generic programming, because it won't call member functions if point isn't a type. But if I change it to (x, y, z).point(), I have the power of UFCS in generic programming, because it will call member function point for me if x has point member function.

As a result, (x, y, z).something(...) is necessary if we want to use UFCS in generic programming while the code loses its readability with x.something(y, z, ...).

0 replies

AbhinavK00 · 2023-11-09T10:27:34Z

AbhinavK00
Nov 9, 2023

Here's why I think this is not worth it. UFCS unified two notations that ALREADY EXISTED but here you are making a new one. This does not help in writing code in any way, because there's no code out there that has this new syntax in it. Also, the advantages that Herb mentions in his paper do not apply here. This is not friendlier to editor, tools or programmer. Most of that friendliness came because dot syntac already existed but this one doesn't.
You gotta understand that UFCS was about extending an already existing syntax but this one is about making a new syntax which makes all the difference.
plus it requires me to type TWO sets of parens

3 replies

msadeqhe Nov 9, 2023
Author

Fair point. So if I want to create a 3D point and if x.point(y, z, true) is not readable, I have to write it like ...
point(x, y, z, true)
..., but this won't call member functions in generic code. Therefore the solution (alternatively) would be to allow ...
point(x, y, z, true)
... to call member functions as described in part 3.2.3 from P3021r0.

EDIT: I've corrected non-member to member.

AbhinavK00 Nov 9, 2023

Not sure, but I don't think UFCS works with contructors. If I'm correct, then the only way to currently contruct a point will be

Point(x,y,z,true);

JohelEGP Nov 9, 2023

This works (https://cpp2.godbolt.org/z/8cWvfjKG9): main: () = { _ = "OK".std::string(); }.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

UFCS with multiple related arguments #811

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 9 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

UFCS with multiple related arguments #811

msadeqhe Nov 8, 2023

Replies: 6 comments · 9 replies

msadeqhe Nov 8, 2023 Author

SebastianTroy Nov 8, 2023

msadeqhe Nov 8, 2023 Author

msadeqhe Nov 8, 2023 Author

SebastianTroy Nov 8, 2023

msadeqhe Nov 8, 2023 Author

msadeqhe Nov 9, 2023 Author

JohelEGP Nov 8, 2023

msadeqhe Nov 9, 2023 Author

msadeqhe Nov 9, 2023 Author

msadeqhe Nov 9, 2023 Author

AbhinavK00 Nov 9, 2023

msadeqhe Nov 9, 2023 Author

AbhinavK00 Nov 9, 2023

JohelEGP Nov 9, 2023

msadeqhe
Nov 8, 2023

Replies: 6 comments 9 replies

msadeqhe
Nov 8, 2023
Author

SebastianTroy
Nov 8, 2023

msadeqhe Nov 8, 2023
Author

msadeqhe Nov 8, 2023
Author

SebastianTroy
Nov 8, 2023

msadeqhe Nov 8, 2023
Author

msadeqhe Nov 9, 2023
Author

JohelEGP
Nov 8, 2023

msadeqhe Nov 9, 2023
Author

msadeqhe Nov 9, 2023
Author

msadeqhe
Nov 9, 2023
Author

AbhinavK00
Nov 9, 2023

msadeqhe Nov 9, 2023
Author