Perché esattamente Java non consente i condizionali numerici come if (5) {…} se C lo fa?


33

Ho questi due piccoli programmi:

C

#include <stdio.h>
int main()
{
    if (5) {
        printf("true\n");
    }
    else {
        printf("false\n");
    }

    return 0;
}

Giava

class type_system {
   public static void main(String args[]) {
       if (5) {
           System.out.println("true");
       }
       else {
           System.out.println("false");
       }
   }
}

che riporta il messaggio di errore:

type_system.java:4: error: incompatible types: int cannot be converted to boolean
       if (5) {
           ^
1 error

La mia comprensione

Finora ho capito questo esempio come una dimostrazione dei diversi sistemi di tipi. C è tipizzato più debolmente e consente la conversione da int a booleano senza errori. Java è più fortemente tipizzato e ha esito negativo, perché non è consentita alcuna conversazione implicita.

Pertanto, la mia domanda: dove ho frainteso le cose?

Quello che non sto cercando

La mia domanda non è collegata al cattivo stile di codifica. So che è male, ma mi interessa il motivo per cui C lo consente e Java no. Pertanto, sono interessato al sistema di tipi di linguaggio, in particolare alla sua forza.


22
@toogley: che cosa vuoi sapere del sistema di tipi in Java? Il sistema dei tipi non lo consente perché la specifica della lingua lo proibisce. I motivi per cui C lo consente e Java non ha nulla a che fare con ciò che è considerato accettabile in entrambe le lingue. Il comportamento risultante dei sistemi di tipo ne è l'effetto , non la causa.
Robert Harvey,

8
@toogley: perché pensi di aver frainteso qualcosa? Rileggendo il testo, non capisco quale sia la tua domanda.
Doc Brown,

26
In realtà, questo non è un esempio di digitazione debole in C. In passato (C89), C non aveva nemmeno un tipo booleano, quindi tutte le operazioni "booleane" operavano effettivamente su intvalori. Un esempio più appropriato sarebbe if (pointer).
Rufflewind,

5
Ho annullato il voto perché non sembra che siano state fatte molte ricerche per capire questo.
jpmc26,

11
Sembra che la domanda originale sia leggermente diversa dalla versione modificata (motivo per cui alcuni dei commenti e delle risposte sembrano rispondere a una domanda diversa). Nella sua forma attuale, non sembra esserci una domanda qui. Che incomprensione? Java si sta comportando esattamente come pensi che dovrebbe essere.
jamesdlin,

Risposte:


134

1. C e Java sono lingue diverse

Il fatto che si comportino diversamente non dovrebbe essere terribilmente sorprendente.

2. C non sta eseguendo alcuna conversione da intabool

Come potrebbe? C non aveva nemmeno un booltipo vero in cui convertire fino al 1999 . C è stato creato nei primi anni '70 e ne iffaceva parte prima ancora di essere C, quando era solo una serie di modifiche a B 1 .

ifnon è stato semplicemente un NOPin C per quasi 30 anni. Ha agito direttamente su valori numerici. La verbosità nello standard C ( collegamento PDF ), anche oltre un decennio dopo l'introduzione di bools in C, specifica ancora il comportamento di if(p 148) e ?:(p 100) usando i termini "diseguale a 0" e "uguale a 0 "anziché i termini booleani" vero "o" falso "o qualcosa di simile.

Convenientemente, ...

3. ... i numeri sono semplicemente ciò su cui operano le istruzioni del processore.

JZe JNZsono le istruzioni di base dell'assembly x86 per la diramazione condizionale. Le abbreviazioni sono " J ump if Z ero" e " J ump if N ot Z ero". Gli equivalenti per il PDP-11, dove ha origine C, sono BEQ(" B ranch se EQ ual") e BNE(" B ranch se N ot E qual").

Queste istruzioni verificano se l'operazione precedente ha comportato uno zero o meno e il salto (o meno) di conseguenza.

4. Java ha un'enfasi molto maggiore sulla sicurezza di quanto C abbia mai fatto 2

E, tenendo conto della sicurezza, hanno deciso che la limitazione ifa booleans valeva il costo (sia per l'implementazione di tale restrizione che per i costi di opportunità risultanti).


1. B non ha nemmeno tipi. Neanche le lingue dell'Assemblea. Eppure i linguaggi B e assembly riescono a gestire bene le ramificazioni.

2. Nelle parole di Dennis Ritchie nel descrivere le modifiche pianificate a B che sono diventate C (enfasi mia):

... sembrava che fosse necessario uno schema di battitura per far fronte ai caratteri e all'indirizzamento dei byte e prepararsi per l'hardware in virgola mobile in arrivo. Altri problemi, in particolare la sicurezza dei tipi e il controllo dell'interfaccia, non sembravano così importanti come lo sono diventati in seguito.


13
Bel punto sulle espressioni booleane nella mappatura C direttamente alle istruzioni del processore. Non ci avevo pensato prima.
Robert Harvey,

17
Penso che il punto 4 sia fuorviante in quanto sembra che C abbia un po 'di attenzione alla sicurezza ... C ti consentirà di fare praticamente tutto quello che vuoi: C presume che tu sappia quello che stai facendo, spesso con risultati straordinariamente disastrosi.
TemporalWolf,

13
@TemporalWolf Dichiari che come se C lasciarti fare ciò che volevi fosse male. La differenza secondo me è che C è stato scritto per i programmatori e ci si aspetta una competenza di base. Java è scritto per scimmie di codice e se riesci a digitare puoi programmarlo. Spesso in modo spettacolare ma a chi importa? Non dimenticherò mai quando un insegnante della classe introduttiva di Java che sono stato costretto a prendere come parte del mio minore CS, ha sottolineato che usare la ricorsione per calcolare i numeri di Fibonnaci potrebbe essere utile perché era "facile da scrivere". Ecco perché abbiamo il software che abbiamo.
DRF,

25
@DRF Uno dei miei professori per un corso di networking in C ha detto "C è come una scatola di bombe a mano con tutti i perni estratti." Hai un sacco di potere, ma è essenzialmente garantito per farti esplodere in faccia. Nella maggior parte dei casi, non vale la seccatura e sarai molto più produttivo con un linguaggio di livello superiore. Ho transcodificato Python in hacky C bit-twiddling per ottenere un aumento della velocità di 6 ordini di grandezza? Sì sì sì. Ma questa è l'eccezione, non la regola. Posso realizzare in un giorno in Python ciò che mi richiederebbe due settimane in C ... e sono un programmatore decente in C.
TemporalWolf,

11
@DRF Data la prevalenza degli exploit di buffer overflow nei software mainstream sviluppati da società leader, a quanto pare non ci si può fidare nemmeno dei programmatori con competenze di base per non sparare.
Ripristina Monica

14

C 2011 Bozza online

6.8.4.1 Le ifdichiarazione

Vincoli

1 L'espressione di controllo di una ifdichiarazione devono avere tipo scalare.

Semantica

2 In entrambe le forme, il primo sottostatement viene eseguito se l'espressione confronta in modo non uguale a 0. Nella elseforma, il secondo sottostatement viene eseguito se l'espressione confronta uguale a 0. Se il primo sottostatement viene raggiunto tramite un'etichetta, il secondo sottostatement è non eseguito.

3 An elseè associato al precedente lessicale più vicino se ciò è consentito dalla sintassi.

Si noti che questa clausola specifica solo che l'espressione di controllo deve avere un tipo scalare ( char/ short/ int/ long/ ecc.), Non specificamente un tipo booleano. Un ramo viene eseguito se l'espressione di controllo ha un valore diverso da zero.

Confrontalo con

Specifiche del linguaggio Java SE 8

14.9 L' ifistruzione

L' ifistruzione consente l'esecuzione condizionale di un'istruzione o una scelta condizionale di due istruzioni, eseguendo l'una o l'altra, ma non entrambe.
    IfThenStatement :
        if Dichiarazione ( espressione )

    IfThenElseStatement :
        if ( Expression ) StatementNoShortIf else Statement

    IfThenElseStatementNoShortIf :
        if ( Expression ) StatementNoShortIf else StatementNoShortIf
L' espressione deve avere tipo booleano Boolean, oppure si verifica un errore in fase di compilazione.

Java, OTOH, richiede specificamente che l'espressione di controllo in ifun'istruzione abbia un tipo booleano.

Quindi, non si tratta di scrivere in modo debole o forte, si tratta di ciò che ciascuna definizione di lingua rispetta come espressione di controllo valida.

modificare

Per quanto riguarda il motivo per cui le lingue sono diverse in questo particolare aspetto, diversi punti:

  1. C era derivato da B, che era un linguaggio "non tipizzato" - in sostanza, tutto era una parola da 32 a 36 bit (a seconda dell'hardware) e tutte le operazioni aritmetiche erano operazioni a numero intero. Il sistema di tipo C era fissato un po 'alla volta, in modo tale che ...

  2. C non aveva un tipo booleano distinto fino alla versione 1999 della lingua. C ha semplicemente seguito la convenzione B di usare zero per rappresentare falsee diverso da zero per rappresentare true.

  3. Java post-date C per un paio di decenni, ed è stato progettato specificamente per affrontare alcune delle carenze di C e C ++. Senza dubbio stringere la restrizione su quella che può essere un'espressione di controllo in ifun'affermazione faceva parte di questo.

  4. Non c'è motivo di aspettarsi ogni due linguaggi di programmazione per fare le cose allo stesso modo. Anche i linguaggi strettamente correlati come C e C ++ divergono in alcuni modi interessanti, in modo tale che tu possa avere programmi C legali che non sono programmi C ++ legali, o programmi C ++ legali ma con semantica diversa, ecc.


Troppo triste, non posso contrassegnare due risposte come "accettate" ..
toogley

1
Sì, questa è una buona riaffermazione della domanda. Ma la domanda si è posta il motivo per cui esiste questa differenza tra le due lingue. Non hai affrontato affatto questo.
Dawood dice di ripristinare Monica

@DawoodibnKareem: La domanda era il motivo per cui C ha permesso la conversione da inta booleanmentre Java non ha fatto. La risposta è che non esiste una tale conversione in C. Le lingue sono diverse perché sono lingue diverse.
John Bode,

Sì, "non si tratta di scrivere in modo debole o forte". Guarda il boxing automatico e il boxbox automatico. Se C avesse quelli, non potrebbe consentire alcun tipo scalare.
Deduplicatore,

5

Molte delle risposte sembrano mirare all'espressione di assegnazione incorporata che si trova all'interno dell'espressione condizionale. (Sebbene si tratti di un tipo noto di potenziale trabocchetto, in questo caso non è l'origine del messaggio di errore Java.)

Probabilmente ciò è dovuto al fatto che l'OP non ha pubblicato il messaggio di errore effettivo e che il ^cursore indica direttamente =l'operatore di assegnazione.

Tuttavia, il compilatore punta al =perché è l'operatore che produce il valore finale (e quindi il tipo finale) dell'espressione che vede il condizionale.

Si lamenta del test di un valore non booleano, con il seguente tipo di errore:

errore: tipi incompatibili: int non può essere convertito in booleano

Testare numeri interi, anche se a volte conveniente, è considerato un potenziale trabocchetto che i progettisti Java scelgono di evitare. Dopotutto, Java ha un vero tipo di dati booleani , che C non ha (non ha un tipo booleano) .

Questo vale anche per i puntatori di test di C per null / non-null via if (p) ...e if (!p) ..., che Java allo stesso modo non consente invece di richiedere un operatore di confronto esplicito per ottenere il booleano richiesto.


1
C ha avere un tipo booleano. Ma è più recente ifdell'affermazione.
MSalters,

3
Il bool di @MSalters C è ancora un numero intero sotto le coperte, quindi puoi farlo bool b = ...; int v = 5 + b;. Questo è diverso dalle lingue con un tipo booleano completo che non può essere usato in aritmetica.
Jules,

Il valore booleano di C è solo un numero intero molto piccolo. "vero" e "falso" potrebbero essere facilmente definiti con macro o altro.
Oskar Skog,

4
@Jules: stai solo sottolineando che C ha una scarsa sicurezza del tipo. Solo perché un tipo booleano viene convertito in un valore intero non significa che sia un tipo intero. Secondo la tua logica, i tipi interi sarebbero tipi a virgola mobile poiché int v = 5; float f = 2.0 + v;è legale in C.
MSalters

1
@MSalters _Boolè in realtà uno dei tipi interi senza segno standard definiti dallo standard (vedere 6.2.5 / 6).
Ruslan,

2

tipi incompatibili: int non può essere convertito in booleano

Sono interessato al motivo per cui C lo consente e Java no. Pertanto, sono interessato al sistema di tipi di linguaggio, in particolare alla sua forza.

Ci sono due parti alla tua domanda:

Perché Java non si converte intin boolean?

Questo si riduce a Java inteso per essere il più esplicito possibile. È molto statico, molto "in faccia" con il suo sistema di tipi. Le cose che vengono automaticamente scritte in altre lingue non sono così, in Java. Devi anche scrivere int a=(int)0.5. La conversione floatin intperderebbe informazioni; uguale alla conversione intin booleane sarebbe quindi soggetto a errori. Inoltre, avrebbero dovuto specificare molte combinazioni. Certo, queste cose sembrano ovvie, ma intendevano sbagliare dal lato della cautela.

Oh, e rispetto ad altre lingue, Java era estremamente preciso nelle sue specifiche, poiché il bytecode non era solo un dettaglio di implementazione interno. Dovrebbero specificare tutte le interazioni, precisamente. Grande impresa.

Perché ifnon accetta altri tipi di boolean?

ifpotrebbe essere perfettamente definito per consentire altri tipi di boolean. Potrebbe avere una definizione che dice quanto segue sono equivalenti:

  • true
  • int != 0
  • String con .length>0
  • Qualsiasi altro riferimento a oggetto che non sia null(e non un Booleanvalore con false).
  • O anche: qualsiasi altro riferimento a un oggetto che non è nulle il cui metodo Object.check_if(inventato da me solo per questa occasione) ritorna true.

Non lo fecero; non c'era bisogno reale, e volevano che fosse il più robusto, statico, trasparente, di facile lettura, ecc. Nessuna funzionalità implicita. Inoltre, l'implementazione sarebbe piuttosto complessa, ne sono sicuro, dovendo testare ogni valore per tutti i possibili casi, quindi le prestazioni potrebbero anche aver giocato un piccolo fattore (Java era un po 'sloooow sui computer di quel giorno; ricorda lì non era un compilatore JIT con le prime versioni, almeno non sui computer che ho usato allora).

Motivo più profondo

Una ragione più profonda potrebbe essere il fatto che Java ha i suoi tipi primitivi, quindi il suo sistema di tipi è diviso tra oggetti e primitivi. Forse, se avessero evitato quelli, le cose sarebbero andate diversamente. Con le regole fornite nella sezione precedente, dovrebbero definire esplicitamente la veridicità di ogni singola primitiva (dal momento che le primitive non condividono una superclasse e non esiste una definizione ben definita nullper le primitive). Ciò si trasformerebbe in un incubo, rapidamente.

prospettiva

Bene, e alla fine, forse è solo una preferenza per i progettisti del linguaggio. Ogni lingua sembra girare a modo suo lì ...

Ad esempio, Ruby non ha tipi primitivi. Tutto, letteralmente tutto, è un oggetto. Si divertono molto facendo in modo che ogni oggetto abbia un certo metodo.

Ruby cerca la verità su tutti i tipi di oggetti che puoi lanciare contro di esso. È interessante notare che non ha ancora alcun booleantipo (perché non ha primitivi) e non ha nemmeno Booleanclasse. Se chiedi quale classe ha il valore true(facilmente disponibile con true.class), ottieni TrueClass. Quella classe ha effettivamente dei metodi, vale a dire i 4 operatori per i booleani ( | & ^ ==). Qui, ifconsidera il suo valore falso se e solo se è uno falseo nil(il nulldi Ruby). Tutto il resto è vero. Quindi, 0o ""sono entrambi veri.

Sarebbe stato banale per loro creare un metodo Object#truthy?che potesse essere implementato per qualsiasi classe e restituire una verità individuale. Ad esempio, String#truthy?avrebbe potuto essere implementato per essere vero per stringhe non vuote o quant'altro. Non l'hanno fatto, anche se Ruby è l'antitesi di Java nella maggior parte dei dipartimenti (digitazione dinamica delle anatre con mixin, classi di riapertura e tutto il resto).

Il che potrebbe sorprendere un programmatore Perl abituato a $value <> 0 || length($value)>0 || defined($value)essere sincero. E così via.

Inserisci SQL con la sua convenzione che nullall'interno di qualsiasi espressione lo rende automaticamente falso, non importa quale. Così (null==null) = false. In Ruby, (nil==nil) = true. Tempi felici.


In realtà, ((int)3) * ((float)2.5)è abbastanza ben definito in Java (lo è 7.5f).
Paŭlo Ebermann,

Hai ragione, @ PaŭloEbermann, ho cancellato questo esempio.
AnoE

Woah lì ... apprezzerebbe i commenti dei downvoter e di quelli che hanno votato per cancellare effettivamente la risposta.
AnoE

In realtà la conversione da inta floatperde anche informazioni in generale. Java proibisce anche questo cast implicito?
Ruslan,

@Ruslan no (lo stesso per long → double) - Immagino che la potenziale perdita di informazioni ci sia solo nei posti meno significativi, e si verifica solo in casi ritenuti non così importanti (valori interi abbastanza grandi).
Paŭlo Ebermann,

1

Oltre alle altre belle risposte, vorrei parlare della coerenza tra le lingue.

Quando pensiamo a un'istruzione if matematicamente pura, comprendiamo che la condizione può essere vera o falsa, nessun altro valore. Ogni grande linguaggio di programmazione rispetta questo ideale matematico; se dai un valore booleano vero / falso a un'istruzione if, puoi aspettarti di vedere un comportamento coerente e intuitivo in ogni momento.

Fin qui tutto bene. Questo è ciò che Java implementa e solo ciò che Java implementa.

Altre lingue cercano di offrire vantaggi per valori non booleani. Per esempio:

  • Supponiamo che nsia un numero intero. Ora definisci if (n)una scorciatoia per if (n != 0).
  • Supponiamo che xsia un numero in virgola mobile. Ora definisci if (x)una scorciatoia per if (x != 0 && !isNaN(x)).
  • Supponiamo che psia un tipo di puntatore. Ora definisci if (p)una scorciatoia per if (p != null).
  • Supponiamo che ssia un tipo di stringa. Adesso definisci if (s)di essere if (s != null && s != "").
  • Supponiamo che asia un tipo di array. Adesso definisci if (a)di essere if (a != null && a.length > 0).

L'idea di fornire if-test abbreviati sembra buona in superficie ... fino a quando non si incontrano differenze di design e opinioni:

  • if (0)viene considerato falso in C, Python, JavaScript; ma trattato come vero in Ruby.
  • if ([]) viene considerato falso in Python ma vero in JavaScript.

Ogni lingua ha le sue buone ragioni per trattare le espressioni in un modo o nell'altro. (Ad esempio, gli unici valori falsi in Ruby sono falsee nil, quindi, 0è verità.)

Java ha adottato un design esplicito per costringerti a fornire un valore booleano a un'istruzione if. Se hai tradotto in fretta il codice da C / Ruby / Python a Java, non puoi lasciare invariati eventuali if test; è necessario scrivere esplicitamente la condizione in Java. Prendersi un momento per mettere in pausa e pensare può salvarti da errori trascurati.


1
Sai che x != 0è lo stesso di x != 0 && !isNaN(x)? Inoltre, è normalmente s != nullper i puntatori, ma qualcos'altro per i non puntatori.
Deduplicatore,

@Deduplicator in quale lingua è la stessa?
Paŭlo Ebermann,

1
Usando IEEE754, NaN ≠ 0. NaN ≠ qualsiasi cosa. Quindi se (x) verrà eseguito e se (! X) eseguirà anche ...
gnasher729

0

Bene, ogni tipo scalare in C, puntatore, booleano (dal C99), numero (virgola mobile o meno) ed enumerazione (a causa del mapping diretto ai numeri) ha un valore di falsità "naturale", quindi è abbastanza buono per qualsiasi espressione condizionale .

Anche Java ne ha (anche se i puntatori Java sono chiamati riferimenti e sono fortemente limitati), ma ha introdotto l'auto-boxing in Java 5.0 che confonde le acque in modo inaccettabile. Inoltre, i programmatori Java esortano il valore intrinseco di digitare di più.

L'unico errore che ha generato il dibattito se limitare le espressioni condizionali di tipo booleano è l'errore di battitura di scrivere un incarico in cui un confronto è stato destinato, che è non è indirizzata limitando il tipo di espressioni condizionale a tutti , ma con l'uso vietando di una naked assegnazione espressione per il suo valore.

Qualsiasi moderno compilatore C o C ++ lo gestisce facilmente, fornendo un avviso o un errore per tali costrutti discutibili se richiesto.
Per quei casi in cui è esattamente ciò che era previsto, l'aggiunta di parentesi aiuta.

Riassumendo, limitare a booleano (e l'equivalente in scatola in Java) sembra un tentativo fallito di fare una classe di errori di battitura causati dalla scelta =per errori di compilazione dell'assegnazione.


Usando ==con operandi booleani, di cui il primo è una variabile (che quindi potrebbe essere digitata in =) all'interno di un ifaccade molto meno spesso che con altri tipi, direi, quindi è solo un tentativo semi-fallito.
Paŭlo Ebermann,

Avere 0.0 -> false e qualsiasi valore diverso da 0.0 -> true non mi sembra affatto "naturale".
gnasher729,

@ PaŭloEbermann: il risultato parziale con effetti collaterali sfortunati, mentre esiste un modo semplice per raggiungere l'obiettivo senza effetti collaterali, è un chiaro fallimento nel mio libro.
Deduplicatore,

Ti mancano gli altri motivi. Che cosa circa il valore di truthy "", (Object) "", 0.0, -0.0, NaN, gli array vuoti, e Boolean.FALSE? Soprattutto l'ultimo è divertente, in quanto è un puntatore non nullo (vero) che scompare da falso. +++ Odio anche scrivere if (o != null), ma salvarmi qualche carattere ogni giorno e farmi passare mezza giornata a fare il debug della mia espressione "intelligente" non è un buon affare. Detto questo, mi piacerebbe vedere una via di mezzo per Java: regole più generose ma senza lasciare alcuna ambiguità.
maaartinus,

@maaartinus: Come ho detto, l'introduzione del disinserimento automatico in Java 5.0 significava che se assegnassero un valore di verità corrispondente alla nullità dei puntatori, avrebbero avuto un bel problema. Ma questo è un problema con l'auto- (un-) boxe, non altro. Un linguaggio senza auto- (un-) boxing come C è felicemente libero da quello.
Deduplicatore,

-1

La mia domanda non è collegata al cattivo stile di codifica. So che è male, ma sono interessato al perché C lo consente e Java no.

Due degli obiettivi di progettazione di Java erano:

  1. Consentire allo sviluppatore di concentrarsi sul problema aziendale. Rendi le cose più semplici e meno soggette a errori, ad esempio la garbage collection in modo che gli sviluppatori non debbano concentrarsi sulle perdite di memoria.

  2. Portatile tra piattaforme, ad es. Eseguito su qualsiasi computer con qualsiasi CPU.

L'uso dell'assegnazione come espressione era noto per causare molti bug a causa di errori di battitura, quindi sotto l'obiettivo n. 1 sopra, non è consentito il modo in cui si sta tentando di usarlo.

Inoltre, deducendo che qualsiasi valore diverso da zero = vero e qualsiasi valore zero = falso non è necessariamente portatile (sì, che ci crediate o no, alcuni sistemi trattano 0 come vero e 1 come falso ), quindi sotto l'obiettivo n. 2 sopra, non è consentito implicitamente . Puoi comunque trasmettere esplicitamente, ovviamente.


4
A meno che non sia stato aggiunto in Java 8, non esiste un cast esplicito tra tipi numerici e booleani. Per convertire un valore numerico in un valore booleano è necessario utilizzare un operatore di confronto; per convertire un valore booleano in uno numerico, in genere si utilizza l'operatore ternario.
Peter Taylor,

È possibile presentare una richiesta per non consentire l'uso di un'assegnazione per il suo valore a causa di tali errori di battitura. Ma considerando la frequenza con cui vedi == true e == false in Java, ovviamente limitare l'espressione di controllo al tipo booleano (facoltativo) non aiuta molto.
Deduplicatore,

Java assicurerebbe banalmente che la portabilità sia "alcuni sistemi considerano 0 come vero e 1 come falso" in quanto è lo zero di Java e falso di Java. Non importa davvero cosa ne pensi il sistema operativo.
maaartinus,

-1

Ad esempio ciò che fanno altre lingue: Swift richiede un'espressione di un tipo che supporti il ​​protocollo "BooleanType", il che significa che deve avere un metodo "boolValue". Il tipo "bool" ovviamente supporta questo protocollo ed è possibile creare i propri tipi supportandolo. I tipi interi non supportano questo protocollo.

Nelle versioni precedenti della lingua, i tipi opzionali supportavano "BooleanType" in modo da poter scrivere "if x" anziché "if x! = Nil". Ciò ha reso molto confuso l'utilizzo di un "bool opzionale". Un valore bool facoltativo ha valori zero, falso o vero e "se b" non verrebbe eseguito se b fosse nullo ed eseguito se b fosse vero o falso. Questo non è più permesso.

E sembra che ci sia un ragazzo a cui non piacciono davvero i tuoi orizzonti ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.