[SYCL] Implicit conversion from id<1> to size_t

[idubinov]

Implements id<1> -> size_t implicit conversion.

Signed-off-by: Igor Dubinov igor.dubinov@intel.com

[romanovvlad]

@AlexeySachkov ping

[bader]

I don't see new functionality added by this patch in the spec.
We should inform developers that they use non-standard functionality (e.g. provide an option to disable non-portable extensions, add a compiler note/warning, etc.)

tagging @mkinsner, @jbrodman, @rolandschulz

[rolandschulz]

We should inform developers that they use non-standard functionality (e.g. provide an option to disable non-portable extensions, add a compiler note/warning, etc.)

Yes. It should only be enabled if all the verbosity/usability extensions are enabled. What's the status of adding a compiler switch to enable/disables extensions (#806)?

[bader]

We should inform developers that they use non-standard functionality (e.g. provide an option to disable non-portable extensions, add a compiler note/warning, etc.)

Yes. It should only be enabled if all the verbosity/usability extensions are enabled. What's the status of adding a compiler switch to enable/disables extensions (#806)?

#806 is about controlling language extensions, where this patch extends library API, which is supposed be configured via preprocessor definitions.

[AlexeySachkov]

Overall, I don't have objections against this patch, but let's guard non-standard things under #ifndef, so users can disable them (don't forget to add test for this new macro)

[AlexeySachkov]

Could you please guard this new non-standard method with some preprocessor macro? Similar to how it is done in #974

It would be also good to have another one macro which allows to disable all non-standard features introduced by header files

[idubinov]

added "SYCL_DISABLE_ID_TO_INT_CONV"

[rolandschulz]

#806 is about controlling language extensions, where this patch extends library API, which is supposed be configured via preprocessor definitions.

I still believe that the user doesn't care whether a language extension is implemented in the FE or in the library and would like to be able to use the same mechanism for both. Note that for C++ this works the same. If I use std=c++17 this enables both the FE and library features. I don't have to manually set preprocessor defines to enable or disable library features. And this regardless of the fact that internally it is just setting a preprocessor flag for the library features based on the compiler flag.

[bader]

#806 is about controlling language extensions, where this patch extends library API, which is supposed be configured via preprocessor definitions.

I still believe that the user doesn't care whether a language extension is implemented in the FE or in the library and would like to be able to use the same mechanism for both. Note that for C++ this works the same. If I use std=c++17 this enables both the FE and library features. I don't have to manually set preprocessor defines to enable or disable library features. And this regardless of the fact that internally it is just setting a preprocessor flag for the library features based on the compiler flag.

Right. But #806 should not block library development.
I see that developers adding library extensions add pre-processor macro and let the compiler know about new switch.
The compiler simplifies user interface by defining pre-processor macro based on compiler flags, but this change can be done separately. Are you okay with that?

[rolandschulz]

The compiler simplifies user interface by defining pre-processor macro based on compiler flags, but this change can be done separately. Are you okay with that?

Yes. I agree.