Perché i parametri const non sono consentiti in C #?

Sembra strano soprattutto per gli sviluppatori C ++. In C ++ abbiamo usato per contrassegnare un parametro come constper essere sicuri che il suo stato non verrà modificato nel metodo. Ci sono anche altri motivi specifici per C ++, come passare const refper passare per ref ed essere sicuri che lo stato non verrà modificato. Ma perché non possiamo contrassegnare come parametri del metodo const in C #?

Perché non posso dichiarare il mio metodo come segue?

    ....
    static void TestMethod1(const MyClass val)
    {}
    ....
    static void TestMethod2(const int val)
    {}
    ....

Oltre alle altre buone risposte, aggiungerò ancora un altro motivo per non mettere la costanza in stile C in C #. Tu hai detto:

contrassegniamo il parametro come const per essere sicuri che il suo stato non verrà modificato nel metodo.

Se const lo facesse davvero, sarebbe fantastico. Const non lo fa. La const è una bugia!

Const non fornisce alcuna garanzia che io possa effettivamente utilizzare. Supponi di avere un metodo che accetta una cosa const. Sono disponibili due autori del codice: la persona che scrive il chiamante e la persona che scrive il chiamato . L'autore del chiamato ha fatto prendere al metodo una const. Cosa possono presumere i due autori sia invariante rispetto all'oggetto?

Niente. Il chiamato è libero di eliminare const e mutare l'oggetto, quindi il chiamante non ha alcuna garanzia che chiamare un metodo che accetta un const in realtà non lo muterà. Allo stesso modo, il chiamato non può presumere che il contenuto dell'oggetto non cambierà durante l'azione del chiamato; il chiamato potrebbe chiamare qualche metodo mutante su un alias non const dell'oggetto const, e ora il cosiddetto oggetto const è cambiato .

La const in stile C non fornisce alcuna garanzia che l'oggetto non cambierà e quindi è rotto. Ora, C ha già un sistema di tipi deboli in cui puoi reinterpretare il cast di un double in un int, se lo vuoi davvero, quindi non dovrebbe sorprendere che abbia un sistema di tipi debole rispetto a const. Ma C # è stato progettato per avere un buon sistema di tipi, un sistema di tipi in cui quando dici "questa variabile contiene una stringa", la variabile contiene effettivamente un riferimento a una stringa (o null). Non vogliamo assolutamente inserire un modificatore "const" in stile C nel sistema dei tipi perché non vogliamo che il sistema dei tipi sia una bugia . Vogliamo che il sistema di tipi sia forte in modo che tu possa ragionare correttamente sul tuo codice.

Cost in C è una linea guida ; in pratica significa "puoi fidarti di me per non provare a mutare questa cosa". Non dovrebbe essere nel sistema dei tipi ; le cose nel sistema di tipi dovrebbero essere un fatto sull'oggetto su cui puoi ragionare, non una linea guida al suo utilizzo.

Ora, non fraintendermi; solo perché const in C è profondamente rotto non significa che l'intero concetto sia inutile. Quello che mi piacerebbe vedere è una forma effettivamente corretta e utile di annotazione "const" in C #, un'annotazione che sia gli umani che i compilatori potrebbero usare per aiutarli a comprendere il codice e che il runtime potrebbe usare per fare cose come la paralellizzazione automatica e altre ottimizzazioni avanzate.

Ad esempio, immagina di poter "disegnare una scatola" attorno a un pezzo di codice e dire " Garantisco che questo pezzo di codice non esegue mutazioni a nessun campo di questa classe" in un modo che potrebbe essere controllato dal compilatore. Oppure disegna una scatola che dice "questo metodo puro muta lo stato interno dell'oggetto ma non in alcun modo che sia osservabile fuori dalla scatola". Un oggetto del genere non può essere automaticamente multi-thread in modo sicuro, ma può essere memorizzato automaticamente . Ci sono tutti i tipi di annotazioni interessanti che potremmo inserire nel codice che consentirebbero ottimizzazioni complete e una comprensione più approfondita. Possiamo fare molto meglio della debole annotazione const in stile C.

Tuttavia, sottolineo che questa è solo una speculazione . Non abbiamo piani fissi per inserire questo tipo di funzionalità in qualsiasi ipotetica versione futura di C #, se ce n'è una, che non abbiamo annunciato in un modo o nell'altro. È qualcosa che mi piacerebbe vedere e qualcosa che potrebbe richiedere l'imminente enfasi sull'elaborazione multi-core, ma niente di tutto ciò dovrebbe essere in alcun modo interpretato come una previsione o una garanzia di qualsiasi caratteristica particolare o direzione futura per C #.

Ora, se quello che vuoi è semplicemente un'annotazione sulla variabile locale che è un parametro che dice "il valore di questo parametro non cambia in tutto il metodo", allora, certo, sarebbe facile. Potremmo supportare locals "readonly" e parametri che sarebbero inizializzati una volta, e un errore in fase di compilazione da modificare nel metodo. La variabile dichiarata dall'istruzione "using" è già di questo tipo locale; potremmo aggiungere un'annotazione opzionale a tutti i locali e parametri per farli agire come variabili "usando". Non è mai stata una funzionalità con priorità molto alta, quindi non è mai stata implementata.

Uno dei motivi per cui non c'è correttezza const in C # è perché non esiste a livello di runtime. Ricorda che C # 1.0 non disponeva di alcuna funzionalità a meno che non facesse parte del runtime.

E diversi motivi per cui il CLR non ha una nozione di correttezza const sono ad esempio:

1. Complica il runtime; inoltre, anche la JVM non ce l'aveva, e il CLR fondamentalmente è iniziato come un progetto per creare un runtime simile a JVM, non un runtime simile a C ++.
2. Se c'è la correttezza const a livello di runtime, dovrebbe esserci la correttezza const nel BCL, altrimenti la funzionalità è praticamente inutile per quanto riguarda .NET Framework.
3. Ma se BCL richiede la correttezza const, ogni linguaggio sopra il CLR dovrebbe supportare la correttezza const (VB, JavaScript, Python, Ruby, F #, ecc.) Questo non accadrà.

La correttezza costante è praticamente una caratteristica del linguaggio presente solo in C ++. Quindi praticamente si riduce alla stessa argomentazione sul motivo per cui il CLR non richiede eccezioni controllate (che è una caratteristica solo del linguaggio Java).

Inoltre, non credo che sia possibile introdurre una funzionalità di sistema di tipo così fondamentale in un ambiente gestito senza interrompere la compatibilità con le versioni precedenti. Quindi non contare sulla correttezza delle cost per entrare nel mondo C #.

Credo che ci siano due ragioni per cui C # non è corretto per la configurazione.

Il primo è la comprensibilità . Pochi programmatori C ++ comprendono la correttezza const. Il semplice esempio di const int argè carino, ma ho anche visto char * const * const arg: un puntatore costante a puntatori costanti a caratteri non costanti. La correttezza delle costanti sui puntatori alle funzioni è un nuovo livello di offuscamento.

Il secondo è perché gli argomenti della classe sono riferimenti passati per valore. Ciò significa che ci sono già due livelli di costanza da affrontare, senza una sintassi ovviamente chiara . Un punto di inciampo simile sono le raccolte (e le raccolte di raccolte, ecc.).

La correttezza della costanza è una parte importante del sistema di tipi C ++. Potrebbe, in teoria, essere aggiunto a C # come qualcosa che viene controllato solo in fase di compilazione (non è necessario aggiungerlo al CLR e non influirebbe sul BCL a meno che non fosse inclusa la nozione di metodi membri const) .

Tuttavia, credo che ciò sia improbabile: la seconda ragione (sintassi) sarebbe abbastanza difficile da risolvere, il che renderebbe la prima ragione (comprensibilità) ancora più un problema.

constsignifica "costante del tempo di compilazione" in C #, non "di sola lettura ma eventualmente modificabile da altro codice" come in C ++. Un analogo approssimativo del C ++ constin C # è readonly, ma è applicabile solo ai campi. A parte questo, non esiste affatto una nozione simile a C ++ di correttezza const in C #.

La logica è difficile da dire con certezza, perché ci sono molte potenziali ragioni, ma la mia ipotesi sarebbe il desiderio di mantenere il linguaggio semplice prima di tutto e i vantaggi incerti dell'implementazione di questo secondo.

Ciò è possibile a partire da C # 7.2 (dicembre 2017 con Visual Studio 2017 15.5).

Solo per Struct e tipi di base ! , non per i membri delle classi.

È necessario utilizzare inper inviare l'argomento come input per riferimento. Vedere:

Vedi: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/in-parameter-modifier

Per il tuo esempio:

....
static void TestMethod1(in MyStruct val)
{
    val = new MyStruct;  // Error CS8331 Cannot assign to variable 'in MyStruct' because it is a readonly variable
    val.member = 0;  // Error CS8332 Cannot assign to a member of variable 'MyStruct' because it is a readonly variable
}
....
static void TestMethod2(in int val)
{
    val = 0;  // Error CS8331 Cannot assign to variable 'in int' because it is a readonly variable
}
....