Avoid unnecessary copy-list-initialization use in the parallel range algorithms

[dmitriy-sobolev]

Summary:

Parallel range algorithms frequently use copy-list-initialization for brevity, but this approach is more restrictive than necessary.

Details:

Example:

oneDPL/include/oneapi/dpl/pstl/hetero/algorithm_ranges_impl_hetero.h

Lines 159 to 169 in 9d72f92

	template <typename _BackendTag, typename _ExecutionPolicy, typename _R, typename _T>
	std::ranges::borrowed_iterator_t<_R>
	__pattern_fill(__hetero_tag<_BackendTag> __tag, _ExecutionPolicy&& __exec, _R&& __r, const _T& __value)
	{
	auto __f = [__value](auto&& __a) { __a = __value; };
	oneapi::dpl::__internal::__ranges::__pattern_walk_n(__tag, std::forward<_ExecutionPolicy>(__exec), __f,
	oneapi::dpl::__ranges::views::all_write(std::forward<_R>(__r)));
	return {std::ranges::begin(__r) + std::ranges::size(__r)};
	}

The statement return {object}; uses copy-list-initialization, which:

• Disallows narrowing conversions.
• Disallows explicit constructors.

While it is unlikely to cause issues in practice, using direct initialization would eliminate even rare potential errors, at the cost of some code duplication.

Preferred alternative ways are shown in this discussion.