Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Report from the February 2020 ISO C++ meeting (Core Language Working Group)

April 23, 2020
Jason Merrill
Related topics:
LinuxOpen source
Related products:
Red Hat OpenShift

Share:

    The first International Organization for Standardization (ISO) C++ meeting of 2020 happened in Prague, Czechia. It was our first time meeting in Prague, though I've been there a few times for the GNU Tools Cauldron. Two of us from Red Hat attended: Jonathan Wakely serves on the ISO C++ Standards Committee Library Working Group (LWG), and I am part of the Core Language Working Group (CWG). (You can see the ISO C++ committee structure here.)

    This was our second meeting after sending the C++20 draft standard out for comments from the ISO C++ national bodies. We finished responses to the last round of comments. That went well, and at the end of the week, we voted to send the resulting C++20 standard to the national bodies for ratification.

    In the next sections, I'll share the thinking behind some of our decisions. Note that this report addresses mostly lower-level issues, unlike my usual trip reports.

    Concepts

    As part of my work on concepts, I contributed wording to the resolution of two closely connected issues.

    Clarify declaration matching

    The first issue is documented in CA104 13.04 [temp.constr]: Clarify declaration matching and partial ordering requiring substitution into constraints. Normally, we try to avoid substituting directly into constraints as written in a requires-clause. Instead, we prefer substitution only on atomic constraints as part of determining whether requirements have been satisfied.

    In the case of comparing a declaration at namespace scope to a declaration in an instantiation of a class template, however, we must allow a direct substitution in some instances. One example is determining whether a specialization matches:

    template <class T> struct A {
        template <class U> U f(U) requires C<typename T::type>;
        template <class U> U f(U) requires C<T>;
      };
    
    // Substitute int for T in above requirements to find match.
      template <> template <class U> U A<int>::f(U) requires C<int>  { }
    

    Hidden non-template friends

    The second issue is from US115 13.6.4 [temp.friend]: Hidden non-template friends need a requires-clause. Until now, it was considered ill-formed for a non-template friend declaration to have a requires-clause. The ISO C++ committee reasoned that it would be unclear whether the non-template friend declaration was trying to match a given constrained overload, or if it was trying to declare friendship only if the requirements are satisfied. We determined that removing constraints on non-template functions renders the first concern meaningless. The second concern remains an undesirable difference from constraint semantics in all other situations.

    If the friend is defined in the class body, then having a requires-clause makes just as much sense as it does on a member function. That is, the clause can be used to define a particular operation for a class template, depending on the characteristics of the template arguments. The library was already allowing this behavior even though the language said it was invalid.

    We resolved to allow the requires-clause on a friend that is defined in a templated class. To avoid the kind of substitution needed for partial specialization matching (as shown in the code sample), we said that any friend template with a constraint that depends on a template parameter of the class must also be defined in the class body. If the constraint only depends on the friend's template parameters, it can be a declaration to match with a template defined at namespace scope.

    Changing concept values

    Continuing with concepts, we addressed Disallow changing concept values. This paper resolves GB046 as "accepted with modifications."

    We noticed when working on concepts in the G++ compiler that the draft allowed the satisfaction of a declaration to vary within a translation unit. This meant, for example, that a declaration could be satisfied by a class becoming complete. Supporting this change slows down the compiler because we could no longer remember the results of a previous check across events such as completing a class definition. The decision to disallow changing concept values means that we don't have to worry about that problem, and we can speed up the compiler again. As a caveat, the current resolution breaks a fair amount of concept code, so more investigation is needed.

    Function template constraints

    For the Proposed resolution for 2019 comment CA 112, we resolved to clarify that a function template can only be considered more constrained than another if the template parameters are otherwise equivalent.

    Modules

    We addressed three proposals dealing with the complications of entities that were once local to a translation unit. In a module interface unit, such entities could become visible to importing translation units:

    • P1815R2: Translation-unit-local entities makes it ill-formed for an exported declaration to expose a translation-local entity.
    • P1779R3: ABI isolation for member functions makes functions defined in a class body within a module no longer implicitly inline, so that they can use local entities without exposing them.
    • P2115R0: Merging of multiple definitions for unnamed unscoped enumerations deals with how we merge unnamed file-scope enumerations from header files that might not have the same set of enumerators in different translation units.

    Each of these patterns previously violated the one definition rule (ODR) but worked in practice. Note that a compiler is free to inline a function that is not declared inline, so the P1779 change need not affect performance. On ELF targets such as GNU/Linux, which allow symbols to be overridden by other definitions, the GNU Compiler Collection (GCC) currently does not inline replaceable functions unless the user specifies -fno-semantic-interposition. We could address this issue in the GCC Modules implementation by assuming no interposition for functions defined in a module interface unit.

    Miscellaneous

    We also addressed several miscellaneous papers. One of these, P0593R6: Implicit creation of objects for low-level object manipulation, offers a new model for when objects are considered to have been created in malloced memory or a char buffer. Any objects necessary are considered to have been created implicitly by the malloc or creation of the buffer. The new model should bring more clarity to type-based aliasing rules in C++.

    We also addressed the proposal P1957R2: Converting from T* to bool should be considered narrowing. It was surprising to realize that we had not previously considered a pointer-to-bool conversion to be narrowing; however, experimentation suggests that making that change would result in far more bugs than false positives.

    The resolution to P1937R2: Fixing inconsistencies between constexpr and consteval functions states that a consteval call can no longer be immediately evaluated in an unevaluated context.

    Conclusion

    The next meeting was scheduled for June 2020 in Varna, Bulgaria. It has been postponed indefinitely due to COVID-19.

    Last updated: March 29, 2023

    Recent Posts

    • How to run a fraud detection AI model on RHEL CVMs

    • How we use software provenance at Red Hat

    • Alternatives to creating bootc images from scratch

    • How to update OpenStack Services on OpenShift

    • How to integrate vLLM inference into your macOS and iOS apps

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue