NVIDIA / NVIDIA/cccl

[FEA]: Settle on a proper policy for non standard extensions

Open
#453 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
2.5k
Forks
486
Avg merge
2d 6h
Merged PRs (30d)
295

Description

### Is this a duplicate?

- [X] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this request and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)

### Area

libcu++

### Is your feature request related to a problem? Please describe.

Currently we are inconsistent whether we follow the standards constraints on whether a feature is available and whether it is `constexpr` or not.

Mostly we are on par with the standard except when we are not. This usually happens when we backport a feature (e.g std::optional) to an earlier standard mode. Usually we document those instances, but usually only for the "big" feature and not for all the necessary machinery.

Same goes for `constexpr` we need some functionality here and there and we usually just change it whenever needed.

I believe we should settle on a few global policies.

1. When will something be available.

Currently only some features are backported. So we be consistent and e.g say "We backport everything to C++14" as a baseline?

2. When will something be `constexpr`

Currently this is purely random. Should we define a consistent policy like. "Everything is constexpr at C++14" *if the language permits

### Describe the solution you'd like

Make everything available at C++14 (exceptions exist such as ranges, where the implementation cost is too great)

Make everything constexpr at C++14. C++11 only allows single line functions, but C++14 more or less gives us all the tools we need.

### Describe alternatives you've considered

We are docuumenting our standard extensions. Technically we would have to mention each backport and each constexpr extension by hand

### Additional context

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.