Namespace for half data type: cl::sycl or no namespace?

[bader]

Khronos SYCL-CTS validates that SYCL implementation defines half data type in cl::sycl space, although it's not clearly stated in the spec that this type must be defined.
Here is all the relevant references in the spec regarding half data type.

4.10.1 Scalar data types.
...
Additional scalar data types which are supported by SYCL within the cl::sycl namespace are described in Table 4.93
...
For the purpose of interoperability and portability, SYCL defines a set of aliases to C++ types within the cl::sycl namespace using the cl_ prefix. These aliases are described in Table 4.94
...
cl_half
Alias to a 16-bit floating-point. The half data type must conform to the IEEE 754-2008 half precision storage format. A SYCL feature_not_supported exception must be thrown if the half type is used in a SYCL kernel fucntion which executes on a SYCL device that does not support the extension khr_fp16

Should we extend the Table 4.93 with half data type?

half data type is mentioned in

4.10.2.2 Aliases
SYCL provides aliases for vec<dataT, numElements> as for the data types: char, short, int, long, float, double, half, cl_char, cl_uchar, cl_short, cl_ushort, cl_int, cl_uint, cl_long, cl_ulong, cl_float, cl_double and cl_half and the data types: signed char , unsigned char, unsigned short, unsigned int, unsigned long, long long and unsigned long long represented with the short hand schar, uchar, ushort, uint, ulong, longlong and ulonglong respectively, for number of elements: 2, 3, 4, 8, 16. For example the alias to vec<float, 4> would be float4.

NOTE: it's not clear here whether half is expected to be defined in cl::sycl namespace or not. It doesn't seem so as this list includes C++ fundamental types, which are not in cl::sycl namespace.

5.1 Half Precision Floating-Point
The half scalar data type: half and the half vector data types: half1, half2, half3, half4, half8 and half16 must be available at compile-time. However if any of the above types are used in a SYCL kernel function, executing on a device which does not support the extension khr_fp16, the SYCL runtime must throw a feature_not_supported exception.

The conversion rules for half precision types follow the same rules as in the OpenCL 1.2 extensions specification [2, par. 9.5.1].

The math functions for half precision types follow the same rules as in the OpenCL 1.2 extensions specification [2, par. 9.5.2, 9.5.3, 9.5.4, 9.5.5]. The allowed error in ULP(Unit in the Last Place) is less than 8192, corresponding to Table 6.9 of the OpenCL 1.2 specification [1].

cl::sycl namespace is not mentioned here neither.

6.5 Built-in scalar data types
In a SYCL device compiler, the standard C++ fundamental types, including int, short, long, long long int need to be configured so that the device definitions of those types match the host definitions of those types. A device compiler may have this preconfigured so that it can match them based on the definitions of those types on the platform. Or there may be a necessity for a device compiler command-line option to ensure the types are the same.

The standard C++ fixed width types, e.g. int8_t, int16_t, int32_t,int64_t, should have the same size as defined by the C++ standard for host and device.
...
half
A 16-bit floating-point. The half datatype must conform to the IEEE 754-2008 half precision storage format. A SYCL feature_not_supported exception must be thrown if the half type is used in a SYCL kernel fucntion which executes on a SYCL device that does not support the extension khr_fp16.
Table 6.1: Fundamental data types supported by SYCL.

Here it seems like this time must be defined in the global namespaces as the rest of the C++ built-in scalar types.

[keryell]

half cannot be defined in the global namespace as it would break a lot of code with some conflicts against some existing half in them...

So I think the only way is to have either cl::sycl::half and/or cl::sycl::cl_half.

The last one seems to be the more logical to me since we are mimicking a type that does exist only in OpenCL.

[AlexeySachkov]

half cannot be defined in the global namespace as it would break a lot of code with some conflicts against some existing half in them...

It seems to me that right now spec requires to do the opposite thing:

4.10.1 Scalar data types
The fundamental C++ data types which are supported in SYCL are described in Table 6.1. Note these types are fundamental and therefore do not exist within the cl::sycl namespace.

half is described in Table 6.1, so, SYCL spec considers it to be a fundamental C++ data type, which looks incorrect (cppreference)

[AerialMantis]

SYCL working group: The specification currently lists half as a fundamental C++ type in section 6.5, so this will need to be corrected. We should change the declaration of half in the specification to cl::sycl::half.

There are also other types in the same table that are not fundamental types so we will look into these internally.

[keryell]

Discussed during 2020/02/18 meeting

half does not exist in C++

Related to KhronosGroup/SYCL-CTS#37

[AerialMantis]

SYCL WG:
We need to update the specification so that half is defined as a type within the cl::sycl namespace. Someone to come back with a PR.

[fraggamuffin]

Mar 24:
need a PR, now we have a proposed solution. this will impact CTS

[fraggamuffin]

wait CTS already testing half in SYCL namespace