Timeline for Function composition in the context of data processing pipelines
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 25, 2024 at 18:38 | comment | added | mahush | I just posted a self answer in which I share the changes I've made based on your review ;-) | |
| Apr 4, 2024 at 20:32 | vote | accept | mahush | ||
| Mar 31, 2024 at 13:09 | comment | added | mahush | it is! So far I've been hesitant to introduce this additional complexity, but the way you've described it makes it sound easy. I think I will give it a try :-) | |
| Mar 30, 2024 at 23:05 | history | edited | ALX23z | CC BY-SA 4.0 |
added 474 characters in body
|
| Mar 30, 2024 at 23:01 | comment | added | ALX23z | @mahush I've just added an idea to improve the functionality, but I'm unsure if it is relevant. | |
| Mar 30, 2024 at 23:00 | history | edited | ALX23z | CC BY-SA 4.0 |
added 474 characters in body
|
| Mar 30, 2024 at 22:52 | comment | added | ALX23z |
@mahush about InvokeResult: Even if it is not designed for end-user usage, they might want to inspect the composed function, say, to test whether or not certain input is acceptable. However, the static_assert will never trigger or cause a compile error upon the inspection.
|
|
| Mar 30, 2024 at 16:35 | history | edited | Blindman67 | CC BY-SA 4.0 |
Formated via markdown
|
| Mar 30, 2024 at 14:59 | comment | added | mahush | Design Choice 2: A valuable hint, thanks and actually much related to issue 2. | |
| Mar 30, 2024 at 14:59 | comment | added | mahush | Issue 4: Indeed, a very good point! In fact, aside from the compose method, every other aspect should be in namespace "detail". | |
| Mar 30, 2024 at 14:58 | comment | added | mahush |
Issue 2: This is very interesting. I think I understand your point, but I don’t see how to fix it, since I want to support generic callables. I am not aware of any way to determine the supported argument types at compile time. Otherwise, ensuring it's something wrapped in std::optional isn't very helpful, I think, since this is already guaranteed by the implementation.
|
|
| Mar 30, 2024 at 14:57 | comment | added | mahush |
Issue 1: Generally, thank you very much for offering insightful feedback. Not sure if I understand issue 1. Your point is that the InvokeResult trait itself is not SFINAE-friendly, isn’t it? Actually InvokeResult is supposed to be an internal helper trait (issue 4 applies here) not intended to be utilized by the library user in order to check the compatibility of callables. Indeed, that could be a use case—one I hadn't considered so far, honestly ;-) However, thanks for pointing that out!
|
|
| Mar 30, 2024 at 7:39 | history | edited | ALX23z | CC BY-SA 4.0 |
added 153 characters in body
|
| Mar 30, 2024 at 7:30 | history | answered | ALX23z | CC BY-SA 4.0 |