Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Public headers require C++23, forcing the same on every consumer

Ouverte
  • Quelque chose ne va pas ?
#928 7 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
42/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
cmake, cpp
Domaine
api, build-system

Piste de recherche

Commencez par CMakeLists.txt:35 et l’en-tête public src/iceberg/result.h, puis suivez les points d’entrée de Catalog listés qui exposent Result. Comparez les fonctionnalités requises de la bibliothèque C++23 avec les toolchains plus anciennes mentionnées dans l’issue. Le travail est terminé lorsque les consommateurs peuvent inclure et utiliser l’API publique sans adopter C++23, tandis que les propres sources de la bibliothèque peuvent continuer à être compilées en C++23 et que la forme de l’API reste inchangée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

CMakeLists.txt:35 sets CMAKE_CXX_STANDARD 23, which is a fine choice for the
library's own sources. The requirement is not confined to them, though.
src/iceberg/result.h includes <expected> and <format>, and defines:

template <typename T, typename E = typename DefaultError<T>::type>
using Result = std::expected<T, E>;

using Status = Result<void>;

Result<T> is the return type of most public entry points —
Catalog::ListNamespaces, ListTables, LoadTable, CreateTable,
StageCreateTable and so on. Every consumer translation unit that calls them
must therefore compile as C++23 as well. std::expected needs libstdc++ 12 or
libc++ 16 and <format> needs libstdc++ 13, so a consumer on an older but still
widely deployed toolchain cannot include the headers at all.

This matters for the engines the library is meant to be embedded in: Velox
builds as C++20, Arrow as C++17, DuckDB as C++11. Integrating leaves two
options — move the whole engine to C++23, or add an isolation layer whose only
purpose is keeping iceberg-cpp headers out of the rest of the build. We are
looking at iceberg-cpp for an Iceberg connector in
Axiom, which builds on Velox at
C++20, and would rather do neither.

Would you consider making the public error type portable while keeping the API
shape unchanged?

#if defined(__cpp_lib_expected)
template <typename T, typename E = typename DefaultError<T>::type>
using Result = std::expected<T, E>;
#else
// vendored fallback with the same interface
#endif

arrow::Result, absl::StatusOr and tl::expected all exist for this reason.
The library's own sources could keep building as C++23; only the public headers
would need to hold a lower baseline.

Happy to send a patch if the direction is agreeable.

cc @PingLiuPing, who is proposing the Iceberg connector for Axiom.

Langage dominant
C++
Étoiles
223
Forks
127
Merge moyen
1 j 13 h
PR mergées (30 j)
28

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/iceberg-cpp

Toutes les issues de apache/iceberg-cpp

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.