[onedpl][ranges] L3 Range based algo API and implementation (memory group)

[MikeDvorskiy]

[onedpl][ranges] L3 Range based algo API and implementation (memory group)

[SergeyKopienko]

Can you explain in comments the idea of works with structure in which data is uninitialized and from this point may have any state?

[dmitriy-sobolev]

int will be set to 0 due to zero-initialization (a sub-case of value initialization). I've corrected the comment above and moved it to this line for clarity.

[SergeyKopienko]

Suggested change

	return {__last};
	return __last;

[MikeDvorskiy]

{} is written intentionally, because it is equivalent to std::ranges::borrowed_iterator_t<_R>{__last} (see the return type for the function).

[SergeyKopienko]

Will we have compile error in the next case?

    return __last;

[SergeyKopienko]

Just for note: practically we never have returns with this form for cases when we return one value, as I seen.

[MikeDvorskiy]

• return __last; tells the function returns an instance of "decltype(__last)"
• return {__last}; tells the function returns an instance of new type (return type), which is created from __last.

[dmitriy-sobolev]

My two cents:

• I like (1) when a function is short: no duplication, you see the return type and {} suggests that is it not the type of __last.
• I do not like (2). It is as (1) but it does not benefit from {}. Adding {} is not that extra number of symbol we should avoid.
• I do not like (3), because I think that having the return type in the function signature is more important.
• I like (4) when a function is large.

It's mostly a matter of preference (and now looks like bikeshedding), but __pattern_uninitialized_fill is small, so I vote for (1).

[SergeyKopienko]

Probably it's a good topic to discuss shortly on our meeting.

UPD: the option (1) described at https://en.cppreference.com/w/cpp/language/list_initialization.html
And this variant has strongly defined semantic when make sense to apply in.
As far as we haven't compile errors here there is no reasons to apply it in the discussing cases I believe.

[danhoeflinger]

I agree here fully with @dmitriy-sobolev . (1) when short, (4) when large.

I think these options make the code most clear and readable, which is my rule of thumb.

[danhoeflinger]

After some discussion with @SergeyKopienko offline and exploring with godbolt, I realized that (1) is not explicitly invoking the constructor, but rather creating an initializer list, and then still using implicit construction of the return type from that initializer list.

https://godbolt.org/z/dTo84fooz

While not the exact same error message, (1) and (2) both don't work with explicit constructors. I guess (1) may give the perception that the type will be changing, (1) is not a shorthand equivalent to (4).

So, I guess perhaps I prefer (4) generally. For short functions, I think (1) and (2) are both fine, its probably not worth a whole lot more time discussing.

[SergeyKopienko]

...from cppreference.com :

https://en.cppreference.com/w/cpp/language/return.html

2) Uses [copy-list-initialization](https://en.cppreference.com/w/cpp/language/list_initialization.html) to construct the return value of the function.

https://en.cppreference.com/w/cpp/language/list_initialization.html

8) in a return statement with a brace-enclosed initializer list used as the return expression and list-initialization initializes the returned object

[SergeyKopienko]

I think we should have additional comments in the code why we don't initialize each field in constructors.

[dmitriy-sobolev]

Added a comment:

// It is sufficient to initialize only one field, the other can be used to verify that the raw memory is correctly set

Actually, I do not see strong reasons to have multiple members, but I suggest leaving it as it is. A side effect is checking the internal test infrastructure where it sets the raw memory.