Does this still generate the correct result? Is it a problem if the Kokkos implementation is more flexible than std::adjacent_difference?

Does this still generate the correct result? Is it a problem if the Kokkos implementation is more flexible than std::adjacent_difference?

No, it does not generate correct result. It would be impossible to do that without duplicating the view, which it does not do.

For view [2, 4, 6, 8, 10], the currently produced result in Serial is [2, 2, 4, 4, 6].

on https://en.cppreference.com/w/cpp/algorithm/adjacent_difference
am i missing it or the precondition is not stated ?

@fnrizzi yes, i didn't see it there when I submitted the issue. I only found it in the other reference.

Update: I guess they just did not copy the text from the standard. It's in it.

on https://en.cppreference.com/w/cpp/algorithm/adjacent_difference am i missing it or the precondition is not stated ?

It does say

If op invalidates any iterator (including any of the end iterators) or modify any elements of the ranges involved, the behavior is undefined.

Update: I guess they just did not copy the text from the standard. It's in it.

Look at Andrey waving the Bible. The current draft has the same paragraph as in cppreference but it also has this remark https://eel.is/c++draft/adjacent.difference#8 that clearly spell out what the precondition involves.

Yes right, I was just surprised the other part of the condition was missing

What do you mean when you say "the other part of the condition [is] missing"?

If op invalidates any iterator (including any of the end iterators) or modify any elements of the ranges involved, the behavior is undefined.

I expected that the fact the ranges cannot overlap was covered by the part of the clause I highlighted above.
You can check with @crtrott or @nliber, they are more fluent in standardese than I am.

I think what you highlight refers to what requirements "op" should have and so what it should do or not doto its arguments. How the result of op is used is a different thing IMO.

In any case, why would it be written so explicitly in working draft but so cryptically in the user documentation?

In any case, it is the responsibility of the user to ensure the preconditions. Here the standard makes no provision for the implementation of adjacent_difference to throw an exception, or signal an error in any way. The only thing that could be "fixed" is that the documentation could state the precondition more clearly.

In order to be a good citizen, Kokkos can try to check the precondition at runtime in certain simple cases and in debug mode ( Cf. @yasahi-hpc PR ), but this is just a nicety and goes beyond what the standard mandates.

In any case, it is the responsibility of the user to ensure the preconditions.

Sure. I do think it falls under the same concept as checking array bounds: a helpful utility to detect errors at early stage.

Sure. I do think it falls under the same concept as checking array bounds: a helpful utility to detect errors at early stage.

Definitely