Today Khronos released the SYCL 1.2 provisional standard, you can read the specification and the press release.   This is a provisional standard, so you can provide feedback about it on the forums.

You can also watch my YouTube video that gives a pitch for the standard, and how it fits in with things.  This video is light on code details, because I want you to understand the basic ideas and then go read the specification for yourself.

Note that this video is unofficial and is not endorsed by Khronos or affiliated with it, the views in here are my own, and my slight mistake and audio stumble at the end is entirely my fault.

As you know, OpenCL is a standard for heterogeneous computing and developers such as myself completely understand the importance of standardization. There are many issues with OpenCL in its current form, but despite my criticisms I respect that it is a standard. My strict adherence to standards can severely limit my productivity, because at this point the only option I have to program OpenCL devices is OpenCL C.

There are people out there who really like C programming, and I understand many of their reasons. I personally find that I am very productive with C++, because I can use tools such as template metaprogramming, operator overloading, and classes to write concise yet efficient code. Despite my occasional frustration with C++, it allows me to work at a high-level of abstraction so that I can do things like design containers that change their implementation at compile-time based on type traits. Unfortunately, OpenCL C forces me to work at a level where my productivity is greatly compromised and it becomes time-consuming for me to develop OpenCL software.

AMD does have some form of C++ kernel language which I will not use, because the entire point of OpenCL is to maintain portability. Perhaps the AMD C++ kernel language can target OpenCL C, and I admit I have not really investigated this. Khronos needs to provide an official OpenCL C++ language so that developers such as myself can get on with being productive and delivering value to customers.

OpenCL will likely never implement standard C++, instead some form of OpenCL C++ will have to be provided. We can’t assume that the hardware will support virtual functions, and we probably don’t want to impose an unnecessary hardware requirement. I am quite happy to have templates, classes, operator overloading, inheritance, and everything else without virtual anything. Standard C++ must be restricted, and rather than relying upon potentially contradictory restrictions imposed by various vendors targeting SPIR themselves, Khronos must take on the responsibility for OpenCL C++ support so that everyone agrees upon the restrictions imposed.

If OpenCL C++ is provided, I am confident that I can leverage my OpenCL programming experience to develop beautiful containers and libraries.