Erste Gehversuche in Swift

Das Verhalten hat sich viel mehr auf den Zugriff bezogen, denn hier entfällt das !. Eigentlich sollten Implicitly Unwrapped Optionals nur verwendet werden, wenn man sicher ist, dass sie einen Wert haben werden, deshalb muss man sie nur in den wenigsten Fällen prüfen. Falls doch, eignet sich auch bei den Implicitly Unwrapped Optionals das Optional Binding bestens.

Ich darf also zusammenfassen: Es gibt angeblich ein theoretisches Sicherheitsproblem, welches praktisch nicht auftaucht und um das zu beseitigen, was also gar nicht existiert, erfinde ich weitere Konstrukte.

Das klingt für mich so sinnvoll wie die ständige Einnahme von Medikamenten, weil ich ja theoretisch krank sein könnte.

Insbesondere hat Apple da etwas unnötigt verkompliziert, was vorher einfach war und perfekt funktioniert hat.

Danke Apple!

Man kann etwas so lange Optimieren bis es gar nicht mehr funktioniert,

Richtig. Der einzige Unterschied ist die Schreibweise im Code beim Zugriff. Hinten raus kommt das selbe.


Wozu brauche ich zwei unterschiedliche Schreibweisen, abhängig davon, wie mein Code funktionieren soll? Nur damit ich mal ein ! weniger tippen muss? Und was mach ich, wenn sich die Funktion meines Codes im laufe der Zeit so ändert, dass die bisher genutzte Schreibweise nicht mehr adäquat ist? Nee, da hätte ich lieber 'ne anständige Code Completion, die das ! für mich bei Bedarf hinschreibt und dafür eindeutigen Code.

Ich glaube der Sinn der Implicitly Unwrapped Optionals ist folgender:

Wie bereits erwähnt, können alle Objekte in Objective-C nil sein. Verwendet man beispielsweise eine Objective-C Methode aus dem Cocoa oder CocoaTouch Framework, erhält man als Rückgabewert ebenfalls ein Objective-C Objekt. Da man hier in so gut wie allen Fällen nie nil erhält, wäre es sehr umständlich, jedes Mal durch Optional Binding oder Forced Unwrapping an den Wert zu gelangen.

Ich bin sowieso der Meinung, Apple hätte mit Swift nichts an den nil-Objekten ändern sollen. Wie Amin schon sagte, das ist eher ein theoretisches Sicherheitsproblem, aber der Mehraufwand, der dadurch in Swift entsteht, ist real.

Bei einer so übersichtlichen, didaktisch klaren Sprach braucht man das doch nicht mehr

SCNR

Claus

Der Witz an den optionals ist unter anderem, daß sie nicht nur für Objekt-Referenzen funktionieren, sondern z.B. auch für enums, ints, floats, structs und so weiter. Man braucht in solchen Fällen also kein Gewürge mit immer wieder unterschiedlichen "reservierten besonderen Werten" mehr, die hoffentlich(!) auch in späteren Versionen des Codes an dieser Stelle wirklich nie als eigentliche Werte vorkommen werden, und vor allem kann der Compiler die ganze Geschichte mit validieren und auch gut optimieren.

Es entmischt abstrakt gesagt die Information über die Gültigkeit eines (ggf. komplexen) Werts von dem Wert selbst, was gerade abseits von Pointern sonst eine beliebte Fehlerquelle ist ("ach, hätte ich hier testen müssen, ob der Rückgabewert an dieser Stelle -1 ist?").

Die Syntax und die damit einhergehenden Pattern sind erst mal ungewohnt, aber das Konzept finde ich recht einleuchtend.

Enums sind deshalb ein schlechtes Beispiel, weil die traditionell in C wegen des fehlenden Namensraumes kaputt sind. (Grund dafür übrigens: Leichtere Lesbarkeit. Noch Fragen?) Benutze ich deshalb schon lange nicht mehr, sondern nur noch Stringkonstanten mit anständigen Namen. Ein == auf eine Referenz ist nicht schwieriger als ein == auf einen Enum.

Aber ich verstehe das auch ansonsten nicht. Ich habe eine Methode, sagen wir eine Suche eines Textes in einem String. Die Methode kann mir "nichts" zurückgeben, um keinen Treffen anzuzeigen. Okay, der Rückgabewert ist optional. Muss ich jetzt immer noch drauf vergleichen. Wo liegt der Vorteil? Dass sie mir das auch formal mitteilt? Solange mir der Compiler nicht sagt, dass ich den Vergleich vergessen habe (was schon deshalb nicht geht, weil er nicht wisse kann, ob ich mir sicher sein darf, dass es einen Treffer gibt), habe ich davon nichts.

Übrigens verstehe ich das gerade bei Pointern nicht. Da gab es schon immer den Unterschied zwischen nil, NULL, whatever und einem referenzierten Wert, der 0 bedeutet. Das Problem stellte sich eher bei numerischen Typen.