Bearbeiten: Nach Void , ich meine Haskells Void type, d. h. leerer Typ, der keine Werte haben kann, aber undefined .
Es gibt eine laufende Diskussion über Swift Evolution, ob das noreturn -Funktionsattribut durch einen tatsächlichen Void -Typ ersetzt werden soll. Um dies zu erreichen, müssen wir sicher sein, dass dies der Plattform echten Nutzen bringen wird. Die Verwendung von Void als Rückgabetyp ist einfach nicht genug.
Ich bitte Sie daher, sehr praktische Beispiele anzugeben, bei denen die Verwendung von Void dem Code Klarheit, Kürze und Generizität verleiht. Vielleicht wird es Klassen verwenden (im Sinne von Haskell), vielleicht Generika, vielleicht wird es Void in einem ADT enthalten.
Aber bitte , geh nicht zu weit in HKT, Monads, all diese High-Level-Sachen. Eine Dienstprogrammfunktion aus der Standardbibliothek ist ebenfalls ein schlechtes Beispiel. Ein perfektes Beispiel wäre Teil eines Arcade-Spiels oder so ähnlich.
(Apropos Void als Typ mit no -Werten, was sich vom Typ mit nur eins -Wert unterscheidet, der normalerweise Unit genannt wird.)
In Haskell Streaming-Bibliotheken wie Streaming oder pipes gibt es Datentypen, die" eine Quelle von Werten vom Typ a darstellen, die, sobald sie erschöpft sind, einen Wert vom Typ r "zurückgibt. Etwas wie Producer a m r (Die m ist eine Basismonade, aber das ist hier nicht relevant.)
Die Erzeuger, die mit einem Wert (von einem Typ, der nichts mit der Art von Werten zu tun hat, die sie beim Laufen aussenden) zurückkehren, sind tatsächlich ziemlich nützlich. Zum Beispiel können Sie einen "Streaming-Splitter" als Funktion mit dem Typ definieren:
%Vor%Diese Funktion segmentiert den Producer, ohne alle Elemente, die dem Split vorausgehen, im Speicher anzusammeln.
Was nun, wenn wir auf der Typenebene ausdrücken wollen, dass ein Produzent niemals aufhört zu produzieren? Wir können dafür sorgen, dass ein Wert vom Typ Void wie Producer a m Void zurückgegeben wird.
Ein weiterer möglicher Anwendungsfall. Angenommen, Sie haben eine Funktion höherer Ordnung, die einen Rückruf akzeptiert, der möglicherweise fehlschlägt. Etwas wie:
%Vor% Was ist, wenn wir eine Version von takesACallback für Funktionen a -> IO r definieren möchten, die niemals fehlschlagen ? Das Ein- und Aussteigen in Either ist mühsam und führt zu einer falschen Musterübereinstimmung, wenn der Wert ausgeht.
Mit Void können wir beginnen, indem wir die a -> IO r in eine a -> IO (Either Void r) umwandeln, sie in takesACallback übergeben und dann den "fake" Fehlerzweig auf der Entweder mit dem absurd :: Void -> a Funktion.
Hier ist ein Beispiel von diesem Trick auf Hackage.
Tags und Links haskell types type-systems curry-howard