Decltype e parentesi C ++ - perché?

L'argomento è stato discusso in precedenza , ma questo non è un duplicato.

Quando qualcuno chiede la differenza tra decltype(a)e decltype((a)), la solita risposta è - aè una variabile, (a)è un'espressione. Trovo questa risposta insoddisfacente.

Innanzitutto, aè anche un'espressione. Le opzioni per un'espressione primaria includono, tra le altre cose:

• (espressione)
• id-espressione

Ancora più importante, il fraseggio per declinare considera le parentesi molto, molto esplicitamente :

For an expression e, the type denoted by decltype(e) is defined as follows:
(1.1)  if e is an unparenthesized id-expression naming a structured binding, ...
(1.2)  otherwise, if e is an unparenthesized id-expression naming a non-type template-parameter, ...
(1.3)  otherwise, if e is an unparenthesized id-expression or an unparenthesized class member access, ...
(1.4)  otherwise, ...

Quindi la domanda rimane. Perché le parentesi sono trattate in modo diverso? Qualcuno ha familiarità con documenti tecnici o discussioni di comitato dietro di esso? La considerazione esplicita delle parentesi porta a pensare che questa non sia una svista, quindi ci deve essere un motivo tecnico che mi manca.

Non è una svista. È interessante notare che in Decltype e auto (revisione 4) (N1705 = 04-0145) c'è un'affermazione:

Le regole del decltype ora lo dichiarano esplicitamente decltype((e)) == decltype(e)(come suggerito da EWG).

Ma in Decltype (revisione 6): formulazione proposta (N2115 = 06-018) una delle modifiche è

L'espressione tra parentesi all'interno del decltype non è considerata come un id-expression.

Non ci sono fondamenti logici nella formulazione, ma suppongo che questa sia una specie di estensione del decltype usando una sintassi un po 'diversa, in altre parole, si intendeva differenziare questi casi.

L'utilizzo per questo è mostrato in C ++ draft9.2.8.4:

const int&& foo();
int i;
struct A { double x; };
const A* a = new A();
decltype(foo()) x1 = 17;        // type is const int&&
decltype(i) x2;                 // type is int
decltype(a->x) x3;              // type is double
decltype((a->x)) x4 = x3;       // type is const double&

Ciò che è veramente interessante, è come funziona con l' returnaffermazione:

decltype(auto) f()
{
    int i{ 0 };
    return (i);
}

Visual Studio 2019 mi suggerisce di rimuovere la parentesi ridondante, ma in realtà si trasformano in decltype((i))quali modifiche restituiscono il valore a int&cui lo rende UB dal ritorno di una variabile locale.

Perché le parentesi sono trattate in modo diverso?

Le parentesi non sono trattate diversamente. È l'espressione id non identificata che viene trattata in modo diverso.

Quando sono presenti le parentesi, si applicano le regole regolari per tutte le espressioni. Il tipo e la categoria di valore vengono estratti e codificati nel tipo di decltype.

La disposizione speciale è lì per poter scrivere codice utile più facilmente. Quando si applica decltypeal nome di una variabile (membro), di solito non si desidera alcun tipo che rappresenti le proprietà della variabile quando viene trattata come un'espressione. Invece vogliamo solo il tipo con cui viene dichiarata la variabile, senza dover applicare una tonnellata di tratti di tipo per ottenerlo. Ed è esattamente ciò che decltypeè specificato per darci.

Se ci preoccupiamo delle proprietà della variabile come espressione, allora possiamo ancora ottenerla piuttosto facilmente, con una coppia extra di parentesi.

Prima del C ++ 11, il linguaggio ha bisogno degli strumenti per ottenere due diversi tipi di informazioni :

• il tipo di un'espressione
• il tipo di una variabile così come è stata dichiarata

A causa della natura di queste informazioni, è stato necessario aggiungere le funzionalità nella lingua (non è possibile eseguirle in una libreria). Ciò significa nuove parole chiave. Lo standard avrebbe potuto introdurre due nuove parole chiave per questo. Ad esempio exprtypeper ottenere il tipo di un'espressione e decltypeottenere il tipo di dichiarazione di una variabile. Sarebbe stata l'opzione chiara e felice.

Tuttavia, il comitato standard ha sempre fatto del suo meglio per evitare di introdurre nuove parole chiave nella lingua al fine di ridurre al minimo la rottura del vecchio codice. La compatibilità con le versioni precedenti è una filosofia di base del linguaggio.

Quindi, con C ++ 11 abbiamo ottenuto solo una parola chiave utilizzata per due cose diverse: decltype. Il modo in cui differenzia tra i due usi è trattando decltype(id-expression)diversamente. È stata una decisione consapevole da parte del comitato, un (piccolo) compromesso.