**File:** modules/core/include/opencv2/core/cuda.hpp
**Change Type:** modified
**Context:** PR #19286: add cuda::Stream constructor with cuda stream flags

**Code Changes:**
```diff
@@ -656,6 +656,18 @@ class CV_EXPORTS_W Stream
     //! creates a new asynchronous stream with custom allocator
     CV_WRAP Stream(const Ptr<GpuMat::Allocator>& allocator);
 
+    /** @brief creates a new Stream using the cudaFlags argument to determine the behaviors of the stream
+
+    @note The cudaFlags parameter is passed to the underlying api cudaStreamCreateWithFlags() and
+    supports the same parameter values.
+    @code
+        // creates an OpenCV cuda::Stream that manages an asynchronous, non-blocking,
```

Review comment:
I believe there is a possibility here. We just haven't found something that you will accept into the codebase and that meets the needs of users like me. What else should we explore? > Exactly in this area there are several issues with "void*" type in constructor. Help me understand. Are you writing as a core team member....that the core team *does not* want to have `void*` in public opencv APIs? I ask because `void* Stream::cudaPtr()` and three others was added 11 months ago on 26 February 2020. These `void*` uses are not old...they are new. Someone in the core team allowed it, here is the commit https://github.com/opencv/opencv/commit/53c0189ed7efe52ad65c38cac04181155e320ca8 It is difficult for contributors to understand how to contribute when there is conflicting information. You are telling me one thing (don't use void*) and only 11 months ago I see it was allowed and merged (with more `void*` use if we look older). My intention is not to complain or make the core team wrong. Instead, I want to contribute in a positive way. I need clear consistent strategy and implementation rules. If I don't have that, it is difficult for me to know how to reverse-engineer and write new code. 🤪 > unique_ptr This is a important need. Static factories return *pointers* to objects; it returns `cuda::Stream *`. This is different than constructors. A constructor returns `cuda::Stream`. If we take the static factory approach, then it returns a pointer...therefore I want to make it safe. No memory leaks, ref count errors, double freeing, ownership, etc! 🔨 These are real pointer problems that happen in opencv (I've found and fixed some) and in apps that use opencv as a library. We are human, we make mistakes. I strongly prefer designs that prevent these mistakes. C++11 and newer has good mechanisms to prevent them. When adding a constructor, we get all the benefits of RAII and scope that I write above. If instead, we have a static factory that returns a pointer, then how do we make it safe? Yes, it could return a unique_ptr instead. That aligns with C++ core guideline 26 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f26-use-a-unique_ptrt-to-transfer-ownership-where-a-pointer-is-needed However, that doesn't align with the typical use of static factories like discussed in guideline https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c50-use-a-factory-function-if-you-need-virtual-behavior-during-initialization. Usually static factories are used for one of two reasons: 1. To return a pointer to a class object from a pool of reusable existing objects, or to return a singleton object. 2. To return a pointer to a subclass based on the parameters passed. It does not return a pointer to itself (the base object) A static factory like below could technically work, but it "feels" strange, lesser, and not a good precedent to set. ```c+ static std::unique_ptr<cv::cuda::Stream> cv::cuda::Stream::makeUniqueFromCudaStream(void*&& cudaStream); ``` This feeling is so strong, I would suggest not doing it. Instead, overloading a function in that `cv::cuda::StreamAccessor` namespace where it can be strongly typed. Pseudocode... ```c++ Stream cv::cuda::StreamAccessor::wrapStream(cudaStream_t&& stream); ``` It is consistent with the already existing wrapStream() function. But, it is not consistent with the already existing `void*` use. Personally, I probably wouldn't use a function like this. It can't be used to initialize a member field; at best a field would be default constructed and then copy assigned from this function. I want a constructor for safety and simplicity. > Try to add move ctor. That is my original post and PR. It is a move constructor.