Timeline for piping a std::tuple into a function
Current License: CC BY-SA 4.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 7, 2021 at 10:15 | history | edited | Toby Speight | CC BY-SA 4.0 |
Add a bit more explanation, as in comments.
|
Aug 7, 2021 at 9:48 | comment | added | user1095108 |
Someone needs to write a well thought-out library along the lines of <ranges> . Until then we are free to roll our own thing.
|
|
Aug 7, 2021 at 9:44 | comment | added | Toby Speight |
I believe that most C++ users would expect an ordinary function (in the pattern of std::for_each() , perhaps), rather than overloading the | operator. As I said in the other question, | may in future become recognised as a composition operator, but it is not so in 2021. That's clearly a matter of opinion where reasonable folk may differ, so I don't see any value in arguing the point!
|
|
Aug 7, 2021 at 8:39 | comment | added | user1095108 |
But when you say piping std::tuple s is unclear, I don't see any clear/standard ways of doing this.
|
|
Aug 7, 2021 at 8:27 | comment | added | user1095108 |
a return value could also indicate, that a conditional pipe is desired, i.e. stop piping when the return value is true or false .
|
|
Aug 7, 2021 at 8:06 | history | edited | Toby Speight | CC BY-SA 4.0 |
added 431 characters in body
|
Aug 7, 2021 at 8:02 | comment | added | Toby Speight |
Yes, that's what I would recommend - but only when f() applied to all the input types is non-void (remember it can have many overloads). It's probably simpler to just convert the tuple to a std::array<std::variant> and then use a transform using std::visit .
|
|
Aug 7, 2021 at 7:55 | comment | added | user1095108 | we could accommodate all of these concerns, I suppose, by optionally returning another tuple. But this is not a serious idea. | |
Aug 7, 2021 at 7:40 | history | answered | Toby Speight | CC BY-SA 4.0 |