This is not the same as writing i in 10…1, which will compile but crash at runtime.

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • torquato schrieb:

    Das hat mit Konzept nichts zu tun.
    Natürlich hat das etwas mit dem Konzept zu tun: Die Syntax von Swift wurde nach der Veröffentlichung so massiv verändert, wie bei keiner anderen Sprache die ich kenne. In C und C++ sind in den letzten Jahrzehnten auch Änderungen vorgenommen worden, die aber durch unterschiedliche Sprachstandards abgemildert wurden. Will sagen: Selbst K&R-Code lässt sich heutzutage noch problemlos übersetzen.

    torquato schrieb:

    Das Entwicklerteam hatte 2014 eine 'public alpha preview' geliefert, das Marketing eine 'New! Wow! Ready for Production. Yeah!!!' verkündet. Man sollte es nicht der Sprache anlasten, wenn DAS in den falschen Hals kommt.
    Meiner Meinung nach sollte die Syntax einer Programmiersprache, die eine Systemsprache werden soll, feststehen, bevor eine Zeile ihrer Implementierung geschrieben wird. Viele Änderungen, die nach der Erstveröffentlichung erfolgt sind, waren auch rein kosmetischer Natur (z. B. Syntax für Array-Deklarationen). Das hätte man auch schon vorher sehen können.

    torquato schrieb:

    aber es hilft jetzt auch nicht mehr, da ständig Flamewares drauf aufbauen zu wollen.
    Was meinst du damit genau?
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    und die Doku ist gelinde gesagt, auch noch verbesserungsbedürftig. Der Unterschied der beiden Varianten geht daraus zumindest nicht hervor.

    Moment. Ist jetzt nicht Dein Ernst, oder? Du beschwerst Dich, daß eine Website, die nicht mit dem Swift-Projekt zusammenhängt und die lediglich inline Code Documentation einer sich in der Entwicklung befindenden API optisch aufbereitet, 'verbesserungsbedürftig' ist?

    Solche Inline Code Documentation sagt idR nur sehr kurz und knapp, was eine Funktion tut, nicht warum und wieso man die für welchen Kontext sich ausgedacht hat. Dieser Zweck wird bestens befolgt. Diesbezüglich ist da an der Stelle eigentlich alles gesagt.

    Sehen wir es sportlich. Mit Swift 3.0 wird wieder ein Wald an Büchern, Tutorials, etc. sprießen, die alles erklären und Geld umsetzen. Hier wird man gesteinigt, wenn man vorher diese Änderungen erwähnt.... ;)
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Moment. Ist jetzt nicht Dein Ernst, oder? Du beschwerst Dich, daß eine Website, die nicht mit dem Swift-Projekt zusammenhängt und die lediglich inline Code Documentation einer sich in der Entwicklung befindenden API optisch aufbereitet, 'verbesserungsbedürftig' ist?

    Solche Inline Code Documentation sagt idR nur sehr kurz und knapp, was eine Funktion tut, nicht warum und wieso man die für welchen Kontext sich ausgedacht hat. Dieser Zweck wird bestens befolgt. Diesbezüglich ist da an der Stelle eigentlich alles gesagt.
    Hast du dir die Doku der beiden Funktionen mal angesehen? Da steht
    1. self anstatt start. (geschenkt)
    2. stride anstatt by. (geschenkt)
    3. bei der zweiten Funktion exakt der gleiche Text wie bei der ersten.
    An knappe Dokus habe ich mich als auch Android-Entwickler ja gewöhnt. Aber bei der Richtigkeit bin ich leider doch etwas pingelig. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Substitution schrieb:

    ein notwendiger Schritt ist, um objective-c als steinalte und ineffektive Sprache abzulösen.
    Du sagst ja selber, Du kannst kein ObjC. Wie kommst Du dann zu dieser Behauptung? Tatsächlich ist ObjC eine Sprache, die mit wenig Erweiterungen von C extrem mächtig und auch effektiv ist.


    Substitution schrieb:

    Aber ich bin der Überzeugung, dass meine Konsequente Haltung gegen objective-c früher oder später aufgehen wird und mein Nur-Swift-Kurs in einigen Jahren Standard sein wird.
    Da stimme ich mit Dir überein. Swift wird halt von Apple gepusht und damit kommt man nicht drum rum. Kann für Neueinsteiger durchaus sinnvoll sein gleich mit Swift zu beginnen.

  • macmoonshine schrieb:

    torquato schrieb:

    Moment. Ist jetzt nicht Dein Ernst, oder? Du beschwerst Dich, daß eine Website, die nicht mit dem Swift-Projekt zusammenhängt und die lediglich inline Code Documentation einer sich in der Entwicklung befindenden API optisch aufbereitet, 'verbesserungsbedürftig' ist?

    Solche Inline Code Documentation sagt idR nur sehr kurz und knapp, was eine Funktion tut, nicht warum und wieso man die für welchen Kontext sich ausgedacht hat. Dieser Zweck wird bestens befolgt. Diesbezüglich ist da an der Stelle eigentlich alles gesagt.
    Hast du dir die Doku der beiden Funktionen mal angesehen? Da steht
    1. self anstatt start. (geschenkt)
    2. stride anstatt by. (geschenkt)
    3. bei der zweiten Funktion exakt der gleiche Text wie bei der ersten.
    An knappe Dokus habe ich mich als auch Android-Entwickler ja gewöhnt. Aber bei der Richtigkeit bin ich leider doch etwas pingelig. ;)
    Das ist ja genau, was ich meine. Du bemängelst Feinheiten der Doku zu etwas, was noch nicht fertig ist.

    @3 Nein, da steht nicht der gleiche Text.

    Ähhh... 'pingelig' ist in dem Fall wohl etwas untertrieben...^^
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Mea culpa. Das or equal hatte ich doch glatt übersehen. ;)

    torquato schrieb:

    Du bemängelst Feinheiten der Doku zu etwas, was noch nicht fertig ist.
    1. Du hast diese Doku hier angeschleppt.
    2. Gegen unfertige Doku zu unfertigen Projekten habe ich nichts.
    3. Die Doku ist aber fehlerhaft. Das ist ein Unterschied.
    4. Was könnte ich wohl mit (geschenkt) gemeint haben?
    „Meine Komplikation hatte eine Komplikation.“

  • gritsch schrieb:

    und warum checkt das der compiler nicht?
    Gute Frage bei einer Sprache, die ihre Anwender vor bösen Programmierfehlern schützen will. +scnr+ ;) Passt irgendwie so garnicht zu Optionals, statischer Typisierung & Co.


    Anscheinend unterstützt der Swift-Compiler kein Loop-Unrolling: bugs.swift.org/browse/SR-203

    Das ist bei Schleifen, deren Elemente über Objekte beschrieben werden, wahrscheinlich auch sehr schwierig.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    gritsch schrieb:

    und warum checkt das der compiler nicht?
    Gute Frage bei einer Sprache, die ihre Anwender vor bösen Programmierfehlern schützen will. +scnr+ ;) Passt irgendwie so garnicht zu Optionals, statischer Typisierung & Co.

    Anscheinend unterstützt der Swift-Compiler kein Loop-Unrolling: bugs.swift.org/browse/SR-203

    Das ist bei Schleifen, deren Elemente über Objekte beschrieben werden, wahrscheinlich auch sehr schwierig.
    Daraus geht aber auch hervor, daß das seit dem 14. Dezember behoben ist.

    Hier der entsprechende commit: github.com/apple/swift/commit/…18b609378f0852251b8f56c12

    Nur, wenn der Compiler in diesen Fällen prüft, ob Loop-Unrolling möglich ist, sollte er natürlich gleich auch prüfen, ob die Schleife überhaupt möglich ist. Dürfte man wohl als Compiler-Bug betrachten.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    und warum checkt das der compiler nicht?
    Gute Frage bei einer Sprache, die ihre Anwender vor bösen Programmierfehlern schützen will. +scnr+ ;) Passt irgendwie so garnicht zu Optionals, statischer Typisierung & Co.
    Anscheinend unterstützt der Swift-Compiler kein Loop-Unrolling: bugs.swift.org/browse/SR-203

    Das ist bei Schleifen, deren Elemente über Objekte beschrieben werden, wahrscheinlich auch sehr schwierig.
    Daraus geht aber auch hervor, daß das seit dem 14. Dezember behoben ist.
    Hier der entsprechende commit: github.com/apple/swift/commit/…18b609378f0852251b8f56c12

    Nur, wenn der Compiler in diesen Fällen prüft, ob Loop-Unrolling möglich ist, sollte er natürlich gleich auch prüfen, ob die Schleife überhaupt möglich ist. Dürfte man wohl als Compiler-Bug betrachten.
    das beispiel dort sollte aber nicht "entfaltet" werden sondern komplett aufgelöst werden in r += 9 oder besser r = r + 9 um sicher zu sein dass es in der nächsten swift version noch funktioniert...

  • macmoonshine schrieb:

    torquato schrieb:

    Nur, wenn der Compiler in diesen Fällen prüft, ob Loop-Unrolling möglich ist, sollte er natürlich gleich auch prüfen, ob die Schleife überhaupt möglich ist. Dürfte man wohl als Compiler-Bug betrachten.
    Ich denke, dass es wahrscheinlich eher knappen Zeitvorgaben geschuldet ist. ;)
    Mhhh... Zeit? Möglich, in diesem Fall aber wohl eher weniger. Im Dezember war man noch gelassen bester Dinge. In den letzten Wochen ist auf GitHub merklich die Schlagzahl erhöht worde. Klar, WWDC steht vor der Tür.
    Ich denke da eher an Überlastung, Kleinteiligkeit, ... Gibt's beim Compilerbau oder allgemein bei Softwareprojekten eigentlich nicht sowas wie ein 'Pflichtenheft'? Na, egal.

    Apropos Zeit. Swift 3.0 wird pünktlich zum Herbst fertig, nur daß dann nicht alles dabei ist, was Swift 3.0 einmal hätte sein sollen. Winding down Swift 3.0; ABI stability deferred Verspätung war meine Voraussage vor ein paar Monaten.
    Da könnten sich Berliner Flughafenbauer mal eine Scheibe von abschneiden. Wir eröffnen BER jetzt endlich offiziell termingerecht und leiten den Flugverkehr einfach temporär über Tegel um. ;)
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • gritsch schrieb:

    torquato schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    und warum checkt das der compiler nicht?
    Gute Frage bei einer Sprache, die ihre Anwender vor bösen Programmierfehlern schützen will. +scnr+ ;) Passt irgendwie so garnicht zu Optionals, statischer Typisierung & Co.
    Anscheinend unterstützt der Swift-Compiler kein Loop-Unrolling: bugs.swift.org/browse/SR-203

    Das ist bei Schleifen, deren Elemente über Objekte beschrieben werden, wahrscheinlich auch sehr schwierig.
    Daraus geht aber auch hervor, daß das seit dem 14. Dezember behoben ist.
    Hier der entsprechende commit: github.com/apple/swift/commit/…18b609378f0852251b8f56c12

    Nur, wenn der Compiler in diesen Fällen prüft, ob Loop-Unrolling möglich ist, sollte er natürlich gleich auch prüfen, ob die Schleife überhaupt möglich ist. Dürfte man wohl als Compiler-Bug betrachten.
    das beispiel dort sollte aber nicht "entfaltet" werden sondern komplett aufgelöst werden in r += 9 oder besser r = r + 9 um sicher zu sein dass es in der nächsten swift version noch funktioniert...

    Ähh... Das verstehe ich jetzt nicht. Könntest Du näher erläutern, was Du damit meinst? Geht's um die Commit-Message, den Code, den Unit Test?
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    gritsch schrieb:

    torquato schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    und warum checkt das der compiler nicht?
    Gute Frage bei einer Sprache, die ihre Anwender vor bösen Programmierfehlern schützen will. +scnr+ ;) Passt irgendwie so garnicht zu Optionals, statischer Typisierung & Co.Anscheinend unterstützt der Swift-Compiler kein Loop-Unrolling: bugs.swift.org/browse/SR-203

    Das ist bei Schleifen, deren Elemente über Objekte beschrieben werden, wahrscheinlich auch sehr schwierig.
    Daraus geht aber auch hervor, daß das seit dem 14. Dezember behoben ist.Hier der entsprechende commit: github.com/apple/swift/commit/…18b609378f0852251b8f56c12

    Nur, wenn der Compiler in diesen Fällen prüft, ob Loop-Unrolling möglich ist, sollte er natürlich gleich auch prüfen, ob die Schleife überhaupt möglich ist. Dürfte man wohl als Compiler-Bug betrachten.
    das beispiel dort sollte aber nicht "entfaltet" werden sondern komplett aufgelöst werden in r += 9 oder besser r = r + 9 um sicher zu sein dass es in der nächsten swift version noch funktioniert...
    Ähh... Das verstehe ich jetzt nicht. Könntest Du näher erläutern, was Du damit meinst? Geht's um die Commit-Message, den Code, den Unit Test?
    um den code in der commit-message:

    Quellcode

    1. for e in [2,3,4] {
    2. r += e
    3. }