Déduire vos intentions

La fonctionnalité de langage en C++17, connue sous le nom de déduction d'argument de modèle de classe, était destinée à remplacer les fonctions de fabrique comme make_pair, make_tuple, make_optional, comme décrit ici : p0091r2Déduction d'argument de modèle pour les modèles de classe (Rev. 5). Cet objectif n'a pas été pleinement atteint et nous aurons peut-être encore besoin de nous en tenir aux fonctions make. Dans ce tutoriel, nous allons décrire brièvement ce qu'est la déduction d'argument de modèle de classe et pourquoi cela fonctionne différemment de ce à quoi les gens s'attendent.

Le problème original était que les gens devaient écrire ce genre de code :

f(std::pair<int, std::vector::iterator>(0, v.begin()));

Être obligé de spécifier le type de 0 et v.begin n'est pas pratique, alors la librairie est apparue avec la fonction de commodité :

f(std::make_pair(0, v.begin()));

Cela fonctionne, car bien que les paramètres modèles des modèles de classes (antérieurs à C++17) ne puissent pas être déduits à partir des arguments du constructeur, ils peuvent être déduits pour les modèles de fonction à partir des arguments de la fonction. C'est une amélioration, bien que parfois vous puissiez vouloir utiliser l'ancienne construction lorsque vous voulez ajuster les types des arguments :

f(std::pair<short, std::string>(0, "literal"));

L'amélioration suivante, en C++17, consistait à autoriser la déduction des paramètres de modèles de classe à partir des arguments passés dans la construction, de sorte que la solution de contournement avec make_pair ne soit plus nécessaire :

// C++17
f(std::pair(0, v.begin()));

Cela fonctionne pour make_pair et la plupart du temps cela fonctionne aussi pour d'autres fabriques, comme make_tuple, sauf quand ce n'est pas le cas.

Prenons le cas suivant :

// o est de type optional<int>
auto o = std::make_optional(int{});
  
// p est de type optional<Threshold>
auto p = std::make_optional(Threshold{});
  
// q est de type optional<optional<int>>
auto q = std::make_optional(std::optional<int>{});

La fonction make_optional encapsule simplement l'argument dans un std::optional. Cela est évident pour les deux premiers cas avec o et p. Concernant la troisième option, nous pouvons avoir des doutes, nous attendre à ce que les optional imbriqués se fondent en un seul, mais ce ne serait pas une bonne idée : l'imbrication peut être volontaire. Par exemple optional<int> pourrait modéliser un « seuil » où l'absence de valeur signifierait que le seuil est l'infini ; alors que <optional<int>> pourrait vouloir dire un « seuil qui ne peut pas être connu ». En fait, le seuil dans le deuxième exemple pourrait être un alias pour optional<int>.

Prenons un cas général dans un modèle :

template <typename T>
void f(T v)
{
  auto o = std::make_optional(v);
  static_assert(std::is_same_v<decltype(o), std::optional<T>>); 
}

Nous voulons que l'assertion soit vérifiée, quel que soit le type avec lequel le modèle est instancié.

Essayons désormais de remplacer make_optional dans nos exemples par une déduction d'argument de modèle de classe :

// o est de type optional<int>
std::optional o (int{});

Ceci fonctionne comme prévu.

// q est de type optional<int> !
std::optional q (std::optional<int>{});

Ceci ne fonctionne pas comme make_optional ! Cela est dû au fait que la logique de déduction des arguments du modèle de classe essaie de deviner votre intention de manière différente dans différents contextes, au lieu de travailler uniformément. Cette logique suppose qu'à la ligne 2 ci-dessous, notre intention était plus vraisemblablement de faire une copie :

std::optional o (1); // intention: wrap
std::optional q (o); // intention: copy

Dans certains cas, cette hypothèse fonctionne, mais cela ne fonctionne pas lorsque notre intention est toujours d’encapsuler un make_optional. Voyons maintenant, ce cas :

// p peut être de type optional<Threshold>
// p peut être de type Threshold
std::optional p (Threshold{});

Nous ne savons pas si p est de type optional<Threshold> ou de type Threshold, car nous ne savons pas si le type Threshold est une instance de std::optional ou pas. Cela signifie qu'au sein d'un modèle, lorsque nous voulons être sûrs de toujours encapsuler T dans un optional<T>, nous devons utiliser un make_optional et nous ne pouvons pas compter sur la déduction d'argument de modèle de classes. C'est l'un des cas où le compilateur peut déduire autre chose que ce à quoi vous vous attendiez. Nous avons une situation similaire avec make_tuple :

std::tuple t (1);           // tuple<int>
std::tuple u (t);           // tuple<int>
std::tuple v (Threshold{}); // ???

Ce problème survient, car nous avons deux attentes contradictoires d'une déduction comme celle-ci. L'une est qu'elle devrait encapsuler, l'autre est qu'elle devrait produire exactement le même type.

std::optional o (1); // intention: wrap
std::optional q (o); // intention: copy

Ces attentes sont contradictoires dans les cas comme la ligne 2 ci-dessus.

std::optional a un deuxième problème similaire. Prenons ce cas :

optional<int> o = 1;
assert (o != nullopt);

Cela fonctionne comme prévu, car optional<U> peut être converti en optional<T>

optional<int> a = 1;
optional<long> b = a;
assert (b != nullopt);

chaque fois que U est convertissable en T, un optional<U> sans valeur est converti en optional<T> sans valeur. C'est intuitif, mais prenons ce cas :

optional<int> a {};
optional<optional<int>> b = a;
 
assert (b == nullopt); // correct?

L'initialisation à la ligne 2 doit-elle être traitée comme une conversion de T en optional<T> (dans ce cas l'assertion échouera) ? Ou doit-elle être traitée comme une conversion de U en optional<T> (dans ce cas l'assertion passera) ? Le compilateur va tenter de deviner nos intentions, mais il va probablement mal deviner. Notez que ce problème sera plus difficile à résoudre si le code ressemble à ceci :

Threshold a {};
optional<Threshold> b = a;
 
assert (b == nullopt); // correct?

ou à ceci :

template <typename T>
void f(T v)
{
  optional<T> o = v;
  assert (o == nullopt); // correct?
}

Pour cette raison, dans un contexte générique (et aussi dans un contexte non générique, lorsque vous ne pouvez pas être sûr des propriétés du type), pour éviter les bogues résultant de l’ambiguïté décrite ci-dessus, vous ne pouvez pas compter sur la logique « intelligente » dans les constructeurs de optional. Vous feriez mieux de déclarer directement vos intentions :

template <typename T>
void f(T v)
{
  std::optional<T> o {std::in_place, v};
  assert (o != nullopt); // correct
}

Pour résumer : les déductions intelligentes fonctionnent généralement comme prévu, mais elles font parfois autre chose.