Swift-evolution

gritsch · 3. Januar 2016, 12:05

funktioniert das auch mit floats?

macmoonshine · 3. Januar 2016, 12:37

Jo: Strideable

gritsch · 3. Januar 2016, 12:39

macmoonshine schrieb:

Jo: Strideable

wie sieht das dann aus?

10.5.strinde(...) oder was?

Michael · 3. Januar 2016, 12:52

gritsch schrieb:

macmoonshine schrieb:

Jo: Strideable

wie sieht das dann aus?
10.5.strinde(...) oder was?

So:

Quellcode

for i in 10.5.stride(to: 0, by: -2.5) {
print(i)
}

Ein Problem hat man allerdings bei vorzeichenlosen Zahlen:

Quellcode

let start: UInt = 10
for i in start.stride(to: 0, by: -3) {
print(i)
}

Das ended mit einem schönen Crash. Das funktioniert nur, wenn der Startwert durch die Schrittweite glatt teilbar ist.

gritsch · 3. Januar 2016, 12:54

Michael schrieb:

gritsch schrieb:

macmoonshine schrieb:

Jo: Strideable

wie sieht das dann aus?10.5.strinde(...) oder was?

So:

Quellcode

for i in 10.5.stride(to: 0, by: -2.5) {

print(i)

}

Ein Problem hat man allerdings bei vorzeichenlosen Zahlen:

Quellcode

let start: UInt = 10

for i in start.stride(to: 0, by: -3) {

print(i)

}

Das ended mit einem schönen Crash. Das funktioniert nur, wenn der Startwert durch die Schrittweite glatt teilbar ist.

aja klar, das ist der konventionellen for-schleife meilenweit überlegen... und natürlich auch viel verständlicher... wahrscheinlich auch noch performanter...

macmoonshine · 3. Januar 2016, 13:07

gritsch schrieb:

10.5.strinde(...) oder was?

Ja, die Zahl 10 hat ein Member 5, welches wiederum eine Methode stride hat.

+scnr+

Amin Negm-Awad · 3. Januar 2016, 14:27

gritsch schrieb:

funktioniert das auch mit floats?

Amin Negm-Awad schrieb:

Übrigens geht das auch mit Fließkommazahlen.

Amin Negm-Awad · 3. Januar 2016, 14:29

Michael schrieb:

gritsch schrieb:

macmoonshine schrieb:

Jo: Strideable

wie sieht das dann aus?10.5.strinde(...) oder was?

So:

Quellcode

for i in 10.5.stride(to: 0, by: -2.5) {

print(i)

}

Ein Problem hat man allerdings bei vorzeichenlosen Zahlen:

Quellcode

let start: UInt = 10

for i in start.stride(to: 0, by: -3) {

print(i)

}

Das ended mit einem schönen Crash. Das funktioniert nur, wenn der Startwert durch die Schrittweite glatt teilbar ist.

Es gibt keine Crashs in Swift, nur Übersetzungsfehler! Dafür ist das erfunden worden!

Man, man, man, JETZT LERNE DAS ENDLICH MAL!!!!!!!!!!!!!

Aber pssst, bitte nicht herumerzählen. Sonst denken die sich noch ein Konstrukt aus mit dem man mitteilen kann, dass Argumente bestimmte Werte-Constraints erfüllen müssen. Ich glaube echt, die schaffen es, aus einem simplen BH eine Mondrakete zu basteln.

torquato · 3. Januar 2016, 14:33

Michael schrieb:

[
Ein Problem hat man allerdings bei vorzeichenlosen Zahlen:

Quellcode

let start: UInt = 10

for i in start.stride(to: 0, by: -3) {

print(i)

}

Das ended mit einem schönen Crash. Das funktioniert nur, wenn der Startwert durch die Schrittweite glatt teilbar ist.

Ach was! Das ist kein Bug. Das ist ein Feature!
Das ist ein Integer Overflow. Besser das knallt einem Entwickler sofort schallend um die Ohren, als daß das später noch Sicherheitslöcher reißt!

Hilfe! Ich will mir in den Fuß schießen, aber das pöse Swift läßt mich nicht!

mattik · 3. Januar 2016, 15:12

gritsch schrieb:

aja klar, das ist der konventionellen for-schleife meilenweit überlegen... und natürlich auch viel verständlicher... wahrscheinlich auch noch performanter...

Natürlich! Und für Intervallschachtelung, oder um irgendwas bit- oder ziffernwseise zu schieben muss man nur eine eigene Zahlenklasse definieren und darauf dann den +-Operator überladen. Total einfach, kompakt, effizient und verständlich! Wir alten Säcke verstehen nur nicht die verborgene Eleganz

macmoonshine · 3. Januar 2016, 15:25

Klar, das Prinzip von Swift ist doch KISS: Keep it strange and skewed.

mattik schrieb:

Und für Intervallschachtelung, oder um irgendwas bit- oder ziffernwseise zu schieben muss man nur eine eigene Zahlenklasse definieren und darauf dann den +-Operator überladen.

Quark, das geht doch viel einfacher: stride liefert einen Generator zurück. Du brauchst also nur die Methode stride(to:multiplicatedBy:) in einer eigenen Kategorie zu überladen, die ein Objekt einer neuen Generatorklasse für exponentielle Schrittweiten zurückliefert. Aber wehe du triffst den Wert to aufgrund von Rundungsfehlern nicht genau, dann gibt's entweder einen Crash oder die Schleife bricht nicht ab.

Michael · 3. Januar 2016, 15:44

tsunamix schrieb:

Ach was! Das ist kein Bug. Das ist ein Feature!
Das ist ein Integer Overflow.

Ach was! Und der Funktion stride() ist es nicht möglich diesen zu verhindern? Bei vorzeichenbehafteten Zahlen klappt das ja schließlich auch. Oder warum erlaubt der Compiler hier überhaupt die Benutzung von vorzeichenlosen Zahlen, wenn stride() mit denen nicht klar kommt? In Swift ist doch alles so Typsicher, oder?

tsunamix schrieb:

Besser das knallt einem Entwickler sofort schallend um die Ohren, als daß das später noch Sicherheitslöcher reißt!

Hilfe! Ich will mir in den Fuß schießen, aber das pöse Swift läßt mich nicht!

Dann stell dir doch mal vor, der Startwert ist zur Übersetzungszeit nicht bekannt oder der ändert sich sogar zur Laufzeit ständig. Da nützt dir auch kein noch so schlauer Compiler.

mattik · 3. Januar 2016, 17:32

macmoonshine schrieb:

Klar, das Prinzip von Swift ist doch KISS: Keep it strange and skewed.

mattik schrieb:

Und für Intervallschachtelung, oder um irgendwas bit- oder ziffernwseise zu schieben muss man nur eine eigene Zahlenklasse definieren und darauf dann den +-Operator überladen.

Quark, das geht doch viel einfacher: stride liefert einen Generator zurück. Du brauchst also nur die Methode stride(to:multiplicatedBy:) in einer eigenen Kategorie zu überladen, die ein Objekt einer neuen Generatorklasse für exponentielle Schrittweiten zurückliefert. Aber wehe du triffst den Wert to aufgrund von Rundungsfehlern nicht genau, dann gibt's entweder einen Crash oder die Schleife bricht nicht ab.

Ach ja, wie konnte ich das nur übersehen? Das ist ja geradezu lächerlich einfach. Wie konnten wir davor nur mit diesem unglaublich komplizierten For-Konstrukt leben?

Edit: Und ich dachte, KISS heißt Keep it surprisingly stubborn...

torquato · 3. Januar 2016, 17:46

Michael schrieb:

Ach was! Und der Funktion stride() ist es nicht möglich diesen zu verhindern?

Ist es die Aufgabe einer fremden Funktion, mit falschen Daten weiterzuarbeiten?

Michael schrieb:

Bei vorzeichenbehafteten Zahlen klappt das ja schließlich auch.

Wirklich? Schon mal ausprobiert, in diesem Fall über den Maximalwert von Int zu gehen? Ich nicht, aber ich wette das Programm faulted dann auch.

Michael schrieb:

Oder warum erlaubt der Compiler hier überhaupt die Benutzung von vorzeichenlosen Zahlen, wenn stride() mit denen nicht klar kommt?

Wieseo? Stride kommt damit klar. Du machst die unlogische Aussage: a) ist positiver Zahlenraum, b) könnte aber negativ werden.

Der Compiler kann solche fälle nicht immer zur Compiletime feststellen. Wenn er es nicht schafft, dann sollte es wenigstens so zur Runtime crashen, daß damit kein (größerer) Schaden mehr angestellt werden kann. Das passiert in dem Fall.

Michael schrieb:

In Swift ist doch alles so Typsicher, oder?

Ist hier doch auch. Du definierst ein UInt und irgendwann verläßt Du dessen Zahlenraum. Das Kompilat sagt nö, und Du sagst männö!

Michael schrieb:

Dann stell dir doch mal vor, der Startwert ist zur Übersetzungszeit nicht bekannt oder der ändert sich sogar zur Laufzeit ständig. Da nützt dir auch kein noch so schlauer Compiler.

Jup. Der Compiler kann nicht alles erkennen. Dann knallt's halt zur Runtime. Hauptsache es entsteht kein korrumpierter Speicherbereich, der noch bis zum Sankt-Nimmerleinstag mitrumgeschleppt wird.

Wenn Du einen Compilerfehler darin siehst, dann schreibe einen Bug-request.

macmoonshine · 3. Januar 2016, 19:55

mattik schrieb:

Wie konnten wir davor nur mit diesem unglaublich komplizierten For-Konstrukt leben?

Ehrlich gesagt, finde ich die Literale viel schlimmer. Was bedeutet denn 10? Ist das eine einfache Zahl oder steckt da vielleicht nicht doch ein abstraktes Konzept hinter? 11 ist ja sehr ähnlich zu 10. Kann man das nicht irgendwie geschickt verallgemeinern, so dass man nicht andauernd den gleichen Code schreiben muss?

Michael · 3. Januar 2016, 20:41

tsunamix schrieb:

Ist es die Aufgabe einer fremden Funktion, mit falschen Daten weiterzuarbeiten?

stride() muss doch eh prüfen, ob der Zielwert erreicht ist. Dann kann es ja auch gleich auf einen Overflow prüfen. Das würde ich jetzt einfach mal erwarten, wenn es denn als Ersatz dienen soll.

tsunamix schrieb:

Wirklich? Schon mal ausprobiert, in diesem Fall über den Maximalwert von Int zu gehen? Ich nicht, aber ich wette das Programm faulted dann auch.

Dachte ich, aber hast recht. Mein erster Test war fehlerhaft. Es knallt da auch, was nur zeigt, das stride() kein vollwertiger Ersatz für for oder while ist.

Marco Feltmann · 3. Januar 2016, 21:09

Michael schrieb:

Ein Problem hat man allerdings bei vorzeichenlosen Zahlen

Nun ja...

C-Quellcode

for( unsigned int i = 10; i > 0; i -= 3 ) {}

Das führt unter C ja auch zu Problemen.
Vielleicht nicht zwingend zu einem Absturz oder wie auch immer das jetzt in Swift neuerdings heißt, aber immerhin zu unerwarteten Ergebnissen.

Interessant finde ich nur die Frage, wie oft so eine Schleife jetzt tatsächlich durchlaufen wird.

C-Quellcode

for( int run = 0, int i = 9; i >= 0; i -= 3, ++run ) { }
NSLog( @"Run #d", run);
// Mutmaßlich sind's 4 Durchgänge

Quellcode

var run = 1
9.stride(to: 0 by: -3) {
run += 1
}

Rein optisch ebenfalls vierDurchgänge.

@warn_unused_result func stride(through end: Self, by stride: Self.Stride) -> StrideThrough<Self>
Return the sequence of values (self, self + stride, self + stride + stride, ... last) where last is the last value in the progression that is less than end.

Also ist die Sequenz jetzt (9,6,3,0), wie man erwarten würde?
Gemäß Doku müsste sie aber (9,6,3,0,-3) sein - was irgendwie widersinnig klingt.

Zum Vergleich:

@warn_unused_result func stride(through end: Self, by stride: Self.Stride) -> StrideThrough<Self>
Return the sequence of values (start, start + stride, start + stride + stride, ... last) where last is the last value in the progression less than or equal to end.

+ähm+
Ja. Nee. Is klar.

tsunamix
Ich habe früher (vor Swift) gelernt, dass man die erwarteten Daten dort prüfen muss, wo man sie benötigt. Also in der Funktion.
Dafür gibt es ja auch diesen hässlichen guard Krams.
Im Übrigen wird in richtigen Programmiersprachen via unsigned int i = 0; i--; der Zahlenraum nicht verlassen.
i ist danach einfach UNSIGNED_INT_MAX und gut.

Thyraz
Es bedeutet weiterhin auch noch überschreiten, übersteigen und stiefeln.

Amin Negm-Awad · 3. Januar 2016, 21:34

tsunamix schrieb:

Michael schrieb:

[
Ein Problem hat man allerdings bei vorzeichenlosen Zahlen:

Quellcode

let start: UInt = 10

for i in start.stride(to: 0, by: -3) {

print(i)

}

Das ended mit einem schönen Crash. Das funktioniert nur, wenn der Startwert durch die Schrittweite glatt teilbar ist.

Ach was! Das ist kein Bug. Das ist ein Feature!
Das ist ein Integer Overflow. Besser das knallt einem Entwickler sofort schallend um die Ohren, als daß das später noch Sicherheitslöcher reißt!

Hilfe! Ich will mir in den Fuß schießen, aber das pöse Swift läßt mich nicht!

Da will sich niemand in den Fuß schießen und da schießt sich niemand in den Fuß. stride() könnte bei 1 als letztes durchführen. Das würde nicht zu irgendwelchen korrumpierte Speicherbereichen führen. Das würde zu einem Programmfehler führen, wenn es nicht genau so gewollt ist!

Wieso da ein Crash zwingend sein soll, ist wirklich nicht ersichtlich.

Was mache ich eigentlich, wenn ich tatsächlich in einer beliebig langen Kette mit jedem 5. Element etwas machen möchte, etwa jede dritte (oder zweite oder fünfte) Karte umdrehen, jeden dritten Stein zur Seite bewegen, … Mit lustigen Offset und Module-Operationen herumhantieren, damit das klappt, was das Normalste der Welt ist? Hurry, es lebe die Lesbarkeit.

Da soll überhaupt nichts crashen, da ist überhaupt nichts falsch. Immer diese theoretisch ausgedachten, in der Wirklichkeit nie vorkommenden Fehlerbilder, nur um die Unfähigkeit einer Programmiersprache zu rechtfertigen.

Amin Negm-Awad · 3. Januar 2016, 21:43

Michael schrieb:

stride() muss doch eh prüfen, ob der Zielwert erreicht ist. Dann kann es ja auch gleich auf einen Overflow prüfen. Das würde ich jetzt einfach mal erwarten, wenn es denn als Ersatz dienen soll.

Swift ist doch rasant schnell. Damit das nicht nur auf Keynote-Folien stimmt, muss man eben jeden Test einsparen.

Michael · 3. Januar 2016, 23:57

Marco Feltmann schrieb:

Michael schrieb:

Ein Problem hat man allerdings bei vorzeichenlosen Zahlen

Nun ja...

C-Quellcode

for( unsigned int i = 10; i > 0; i -= 3 ) {}

Das führt unter C ja auch zu Problemen.
Vielleicht nicht zwingend zu einem Absturz oder wie auch immer das jetzt in Swift neuerdings heißt, aber immerhin zu unerwarteten Ergebnissen.

Das ist richtig, aber da kann ich anhand der Werte, Vergleiche, Operationen erkennen, was da passiert. Wenn eine Funktion mir anbietet zu einem Zielwert „zu schreiten“, dann kann ich nicht erkennen, dass die Funktion intern trotzdem über den Zielwert hinausschießt. Und das bei einer Programmiersprache, die sich „Designed for Safety“ auf die Fahne geschrieben hat, die es eben besser/sicherer machen will, als C.