Dan Hoeflinger

> For me it's looks like we should implement all these operators only for C++17 version and implement `` operator for C++20. I'm wondering if it is a good idea...

> Let me ask: what's a motivation for that internal::tuple functionality extending? Other words, where in OneDPL impl do we need such functionality? Example: Someone has a `zip_iterator` of two...

> I'd be willing to drop (3) from this PR, it causes the most complication in implementation and has the least utility. I've re-organized the code to make clear which...

> @danhoeflinger It's not the result of you PR, but for `operator=(const tuple& other)` what about the case when `this == &other' ? I mean probably we should avoid self-assignment......

After an offline discussion with @rarutyun , we have decided not to target the coming release with this PR, and take some time to investigate some context around it. Specifically,...

> @danhoeflinger How do you think, should we support three-way comparison `` too (https://en.cppreference.com/w/cpp/language/operator_comparison)? I think we discussed this before https://github.com/oneapi-src/oneDPL/pull/1472#issuecomment-2032405450 . I did find the macro which I believe...

> Regarding `operator` - since there are internal helpers `__equal` and `__less` anyway, why not implement a three-way comparison helper instead and use it in all operators? Then if the...

> The key difference perhaps is that both `==` and ` But I am not that bothered about supporting the spaceship operator. Duplicating essentially the same code three times bothers...

@SergeyKopienko @akukanov After exploring this a little bit, and running into a few complexities of the spaceship operator, I propose to merge this PR with the current level of functionality...

@al42and Thank you very much for the feedback. This is something we are aware of as a potentially beneficial feature for users who are interested in improved performance at the...