Skip to content

Conversation

@kboyarinov
Copy link
Contributor

@kboyarinov kboyarinov commented Dec 12, 2025

Description

Add a comprehensive description of proposed changes

Fixes #1898

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

  • bug fix - change that fixes an issue
  • new feature - change that adds functionality
  • tests - change in tests
  • infrastructure - change in infrastructure and CI
  • documentation - documentation update

Tests

  • added - required for new features and some bug fixes
  • not needed

Documentation

  • updated in # - add PR number
  • needs to be updated
  • not needed

Breaks backward compatibility

  • Yes
  • No
  • Unknown

Notify the following users

List users with @ to send notifications

Other information

vossmjp
vossmjp previously approved these changes Dec 15, 2025
Copy link
Contributor

@vossmjp vossmjp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines -21 to -24
.. literalinclude:: ./examples/blocked_nd_range_ctad_example.cpp
:language: c++
:start-after: /*begin_blocked_nd_range_ctad_example_1*/
:end-before: /*end_blocked_nd_range_ctad_example_1*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should we do with the usage examples? Is there a place in the Developer Guide to use those, or should we just delete the file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this particular example, I guess it can be removed since it contains basic CTAD scenarios and small part of examples from the specification and the RFC.

Comment on lines +322 to +323
blocked_nd_range range({T{0}, T{100}}, {T{0}, T{100}, T{5}}, {T{0}, T{100}}, {T{0}, T{100}, T{5}});
static_assert(std::is_same_v<decltype(range), blocked_nd_range<T, 4>>);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a check on the grainsizes of the resulting subranges. For example, this four-dimensional range seems to be a good candidate for this as it includes subranges with different grainsizes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this test case is a right place for any checks like this since setting a correct grainsize is a work for constructor, not a deduction guide.
A deduction guide should only deduce the correct type of the range and the correctness of parameters should be checked in a test for constructors (which do not use deduction guides).

By the way, I have checked such a test case for blocked_nd_range and found out that it do not contain any checks for most cases:) Updated the test case in a separate PR #1933.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Productize deduction guides for blocked_nd_range

4 participants