Migration nach Swift 2.0

gandhi · 9. Juni 2015, 15:38

Hi,

hat schon mal jemand die Migration nach Swift 2.0 ausprobiert? Trotz Assistent (Der erst nicht funktionierte, aber gut ,ist ja erst die erste Beta) gibt's 'ne Menge von Hand zu tun. Das wird die Leute mit einem Haufen Swift 1.2-Code richtig freuen

Gefallen hat mir der Unterstrich, der bei der Unmenge an "if let"-Konstrukten eingesetzt werden kann, wenn man die Variable nicht benötigt (Auch bei for-Schleifen).

Ob jetzt do/try/catch die tolle Neuheit ist, sei mal dahingestellt. Den Rest muss ich mir noch ansehen...

ciao

gandhi

macmoonshine · 9. Juni 2015, 16:12

gandhi schrieb:

Gefallen hat mir der Unterstrich, der bei der Unmenge an "if let"-Konstrukten eingesetzt werden kann, wenn man die Variable nicht benötigt (Auch bei for-Schleifen).

Wozu legt man eine Variable dann überhaupt an?

EDIT: Die ersten Beta-Versionen sind meistens eher für die Tonne gedacht. Nach zwei Beachballs in 5 Minute habe ich beschlossen zu warten.

gandhi · 9. Juni 2015, 16:23

macmoonshine schrieb:

Wozu legt man eine Variable dann überhaupt an?

Na ja, wenn Dich die Schleifenvariable in einer for-Schleife gar nicht interessiert, weil Du z.B. immer 27 Zufallszahlen ausgeben willst. Das geht jetzt mit:

Quellcode

for _ in 1...27
{
}

macmoonshine schrieb:

Die ersten Beta-Versionen sind meistens eher für die Tonne gedacht

Tja, und schon hänge ich fest: Eines meiner Targets lässt sich mit Xcode 7 nicht mehr linken. Sowas linkes

! Obskure Fehlermeldung, und, ich schwör's, ich hab' nix gemacht.

macmoonshine · 9. Juni 2015, 16:44

gandhi schrieb:

Na ja, wenn Dich die Schleifenvariable in einer for-Schleife gar nicht interessiert, weil Du z.B. immer 27 Zufallszahlen ausgeben willst. Das geht jetzt mit:

Richtig, bei for kommt sowas schonmal vor. Da wäre vielleicht for 1...27 eleganter. Bei if ist es meines Erachtens relativ sinnlos. Erst einen Nullpointer-Vergleich in einer Zuweisung verstecken und dann die Zuweisung nicht verwenden. Klingt großartig

chartus · 10. Juni 2015, 14:50

ist das mit dem underline nicht üblich um tuppel zu sprengen?

mir war so das es zb in lua so war?

gandhi · 10. Juni 2015, 14:55

chartus schrieb:

mir war so das es zb in lua so war?

Lua kenne ich nicht, hier geht's ja um Swift

FWerewolf · 10. Juni 2015, 14:55

Ahja ... weltbewegende und extrem wichtige Änderung:

Code löst sich nicht mehr übersetzen, weil - jetzt kommt's - println has been renamed to print

fredor · 10. Juni 2015, 15:33

Hmmm... wir war so Print gab es auch zuvor. Println hatte halt noch ein CR/LF und jeder Print hat das nur hinten rangehängt. Was ist mit dem alten Print passiert?

FWerewolf · 10. Juni 2015, 16:10

print macht jetzt standardäßig ein CR/LF dahinter.
Wahrscheinlich hat Apple gemerkt, dass die meiste Zeit println benutzt wurde und es vereinfacht.

FWerewolf · 10. Juni 2015, 16:27

oh der Spass geht weiter

@availability has been renamed to @available
DebugPrintable has been renamed to CustomDebugStringConvertible

macmoonshine · 10. Juni 2015, 16:54

Ah, jetzt verstehe ich das mit der Nummer hinter Swift: Das ist keine Versionsnummer sondern die Anzahl der (unnötigen) Änderungen am Sprachstandard pro Minute.

+scnr+

gritsch · 10. Juni 2015, 16:55

fredor schrieb:

Hmmm... wir war so Print gab es auch zuvor. Println hatte halt noch ein CR/LF und jeder Print hat das nur hinten rangehängt. Was ist mit dem alten Print passiert?

bestehender code hat also plötzlich jeweils zwei newlines?

GG

macmoonshine · 10. Juni 2015, 17:00

FWerewolf schrieb:

print macht jetzt standardäßig ein CR/LF dahinter.

Ich hoffe, es ist nur ein LF. Wir sind doch schließlich unter UNIX!

Thyraz · 10. Juni 2015, 20:42

gritsch schrieb:

fredor schrieb:

Hmmm... wir war so Print gab es auch zuvor. Println hatte halt noch ein CR/LF und jeder Print hat das nur hinten rangehängt. Was ist mit dem alten Print passiert?

bestehender code hat also plötzlich jeweils zwei newlines?
GG

Kann man damit bei Swift noch was anderes anfangen als eine Logausgabe, oder warum ist das ~~gritsch~~ kritisch?

gritsch · 10. Juni 2015, 20:46

stell dir vor jemand gibt mehrere verschiedene sachen in verschiedenen print aufrufen aus. er erwartet das ganze dann in einer zeile weil er ja kein newline angegeben hat und in der doku stand dass auch keine newline angehängt wird...
...und plötzlich sind dann da doch newlines und man muss seinen code wieder ändern... (unabhängig ob das beschriebene szenario sinn macht oder nicht - funktionen sollten nciht plötzlich ihr dokumentiertes verhalten ändern).

Michael · 10. Juni 2015, 21:17

gritsch schrieb:

funktionen sollten nciht plötzlich ihr dokumentiertes verhalten ändern

Zumindest nicht, wenn man behauptet es sei keine Beta Software mehr.

macmoonshine · 10. Juni 2015, 22:10

Thyraz schrieb:

Kann man damit bei Swift noch was anderes anfangen als eine Logausgabe, oder warum ist das gritsch kritisch?

In einem Kommandozeilenprogramm sollen ja gelegentlich auch Ausgaben auf die Konsole vorkommen, die nix mit Logging zu tun haben.

Für's Loggen sollte man sowieso lieber NSLog verwenden.

FWerewolf · 10. Juni 2015, 22:33

vor allem übersetzt der Compiler nicht mehr, wenn da println steht ... es ist ein Error, keine Warning

gritsch · 10. Juni 2015, 22:36

FWerewolf schrieb:

vor allem übersetzt der Compiler nicht mehr, wenn da println steht ... es ist ein Error, keine Warning

es geht um den fall dass vorher jemand "print" (ohne "ln") verwendet hat und damit gerechnet hat dass es auch kein newline selbst hinzufügt (so wie es in der doku stand) - doch nun wird da plötzlich auch ein newline ausgegeben? Irgendwie kann ich mir das gar nicht vorstellen. wie gibt man dann text aus OHNE eine newline mit am ende auszugeben? geht nicht mehr?
Aber wie gesagt: es kann einfach nicht sein dass sich plötzlich das verhalten von funktionen derart ändert!

Michael · 10. Juni 2015, 23:15

gritsch schrieb:

wie gibt man dann text aus OHNE eine newline mit am ende auszugeben? geht nicht mehr?

Doch geht noch:

print("Foo", appendNewline: false);

Ob das nun besser ist?