Wat te verwachten van Swift 3

Je weet waarschijnlijk dat Swift 3 later dit jaar komt. Het is de eerste release waarin het harde werk van een fantastische community is verwerkt. Tientallen voorstellen werden ingediend sinds Apple Swift in 2015 opende en tientallen werden geaccepteerd na zorgvuldige overweging door het kernteam. In dit artikel bekijken we enkele van de belangrijke veranderingen in Swift 3.

Wat is Swift 3 over?

Het kernteam heeft een zeer duidelijk doel voor ogen met de release van Swift 3, waarmee een solide basis wordt gecreëerd voor de Swift-programmeertaal. Op WWDC 2016 benadrukte Chris Lattner dat Swift 3 een reeks van veranderlijke veranderingen introduceert met de bedoeling om de fundamenten goed te krijgen. Dat is het gemeenschappelijke thema van de aankomende release. Dit betekent het doorbreken van bestaande functies, het verwijderen van een aantal functies en het verbeteren van de basis van de taal.

Het Swift-evolutieproject is een echt succesverhaal voor iedereen die bij de Swift-gemeenschap betrokken is. Het engagement was enorm en het resultaat is Swift 3. Apple is transparant over het releaseproces en snapshots van Swift 3 zijn beschikbaar op de Swift-website en opgenomen in Xcode 8, die op het moment van schrijven in beta is.

Meer dan snel

De Swift 3-release richt zich niet alleen op de Swift-programmeertaal, het bevat ook substantiële wijzigingen in de toolchain, de standaardbibliotheek en de interoperabiliteit van de taal met Cocoa. Onthoud dat Swift meer is dan een taal. Wanneer we over Swift praten, denken we meestal alleen aan de taal, maar het bevat ook de standaardbibliotheek en de pakketbeheerder.

Broncompatibiliteit

Als je met Swift hebt gewerkt, dan weet je dat het migreren van een codebase van de ene naar de andere versie niet moeilijk is. Helaas zal het migreren van een project naar Swift 3 niet anders zijn.

Dat gezegd hebbende, is het primaire doel van Swift 3 ervoor te zorgen dat de overgang van Swift 3 naar toekomstige versies van de taal niet zo zal zijn. Broncompatibiliteit is een belangrijk aandachtspunt van Swift 3.

Geweldigheid

Swift was ontworpen als een moderne programmeertaal, maar het was even belangrijk om een ​​taal te creëren die er goed uitzag en die ... nou ... geweldig was. Met Swift 3 blijft het team "de taal optimaliseren voor awesomeness", zoals Chris Lattner het verwoordt.

Hoewel er veel veranderingen optreden, is het nettoresultaat een taal die er goed uitziet en er geweldig uitziet. Swift 3 is een genot om te gebruiken. De wijzigingen aan Core Graphics en Grand Central Dispatch, die we in een ogenblik bespreken, zijn mooie voorbeelden.

Wat verandert er?

Genoeg over hoe geweldig Swift is en hoeveel ongelofelijker Swift 3 zal zijn. In de rest van dit artikel zou ik willen focussen op enkele van de belangrijkste veranderingen die in Swift zijn geïntroduceerd. 3. Houd in gedachten dat Swift 3 blijft evolueren tot de officiële release later dit jaar.

API

Leesbaarheid

Er werd veel tijd en energie besteed aan het verbeteren van de API van de Swift-taal. De veranderingen zijn significant, dat valt niet te ontkennen. Maar het resultaat is heel erg leuk. Met Swift 3 streeft het kernteam naar een API die zich richt op leesbaarheid en toegankelijkheid.

Hoewel velen van ons gewend zijn geraakt aan de breedsprakigheid van Objective-C, neemt de nieuwe Swift-API een andere aanpak door alleen de nadruk te leggen op en zich te concentreren op de essentie. Bekijk het volgende voorbeeld van Swift 2.2.1. Dit voorbeeld zou er bekend uit moeten zien als je wat tijd hebt besteed aan Swift ... of Objective-C.

parentViewController.presentViewController (newViewController, geanimeerd: true, completion: nil)

In Swift 3 ziet dit codefragment er enigszins anders uit zoals u hieronder kunt zien.

parentViewController.present (newViewController, geanimeerd: true, completion: nil)

De Swift-gemeenschap realiseerde zich dat het niet nodig is om een ​​verwijzing op te nemen naar wat wordt gepresenteerd, omdat die informatie al in de eerste parameter is opgenomen. Als gevolg hiervan wordt de naam van de methode beter leesbaar en beknopter. Een duidelijke verbetering als je het mij vraagt.

Dit is een rode draad in Swift 3. Verschillende van de voorstellen die werden aanvaard en opgenomen in Swift 3 waren gericht op vereenvoudiging en het verwijderen van cruft uit de taal. De Swift-API werd aanvankelijk sterk beïnvloed door de uitgebreide aard van Objective-C. De leesbaarheid is geweldig, maar Swift 3 snijdt terug op breedsprakigheid zonder afbreuk te doen aan de leesbaarheid.

De Swift-gemeenschap is van mening dat bij het ontwerp van een API altijd rekening moet worden gehouden met de API en dat dit duidelijk zichtbaar is in de wijzigingen die in Swift 3 zijn geïntroduceerd. Ik ben er zeker van dat u het ermee eens bent dat de vernieuwde API eruit ziet-en leest-great.

Labeling-parameters

Een andere belangrijke verandering die veel ontwikkelaars verwelkomen, is de consistente ondertekening van functie en methoden door standaard het eerste parameteretiket op te nemen. Dit is hoe een typische functie eruit ziet in Snel 2.2.1. Standaard wordt het eerste parameterlabel weggelaten wanneer de functie wordt opgeroepen.

func setupView (weergave: UIView, withConfiguration configuration: Configuration) // ... setupView (view, withConfiguration: configuration)

Dat is niet langer het geval in Swift 3. De eerste parameter krijgt niet langer een speciale behandeling, wat een zeer welkome verandering is.

func setupView (weergave: UIView, withConfiguration configuration: Configuration) // ... setupView (weergave: view, withConfiguration: configuration)

Vanwege deze wijziging kunt u het bovenstaande voorbeeld verder verbeteren door de verwijzing naar de weergave in de functienaam weg te laten.

func setup (view: UIView, withConfiguration configuration: Configuration) // ... setup (view: view, withConfiguration: configuration)

Importeer als lid

Het werken met C API's in Swift heeft er altijd lomp en onbeholpen uitgezien. Core Graphics-functies worden bijvoorbeeld geïmporteerd als globale functies, wat geen geweldige oplossing is en als gevolg daarvan voelt het gebruik van Core Graphics in Swift niet geweldig.

Hetzelfde geldt voor Grand Central Dispatch. In het volgende voorbeeld gebruiken we Grand Central Dispatch om een ​​taak asynchroon naar een achtergrondwachtrij te verzenden.

dispatch_async (dispatch_get_global_queue (DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) // ...

In Swift 3 voelt de API veel meer aan als een native Swift API. Functies worden geïmporteerd als methoden, wat resulteert in de volgende syntaxis in Swift 3.

DispatchQueue.global (attributen: .qosBackground) .async // ...

Functies verwijderen

De Swift-gemeenschap stemde ook in met het verwijderen van een aantal functies, waarvan sommige een paar verhitte discussies hebben opgewekt. Ik zou er graag vier willen noemen.

C-Style voor Loops

Lijkt dit je bekend?

for (var i = 0; i < 5; i++)  print(i) 

C-stijl voor loops zijn niet langer beschikbaar in Swift 3. Wacht. Wat? Waarom? Dat is een heel goede vraag. Je kunt het voorstel, ingediend door Erica Sadun, lezen op GitHub. Dit brengt ons bij de volgende controversiële verandering.

Afscheid te nemen van ++ en --

Spoedig na open sourcing Swift diende Chris Lattner, de maker van Swift, een voorstel in om de ophogende en verlaagde operators uit de taal te verwijderen. In zijn voorstel vermeldt hij dat deze operatoren al vroeg in de ontwikkeling van Swift "zonder veel aandacht" zijn toegevoegd. De Swift-API opruimen en verwarring voorkomen, ++ en -- zijn niet langer beschikbaar in Swift.

var a = 0 a++

Raak echter niet in paniek. De oplossing is eenvoudig. Je hoeft je niet druk te maken.

var a = 0 a + = 1

Niet meer var parameters

Als u bekend bent met functies in Swift, weet u dat de parameters van een functie standaard constant zijn. U kunt dit gedrag wijzigen door een parameternaam vooraf te gaan met de var trefwoord. Voor variabele parameters wordt een variabele kopie van de parameter doorgegeven aan de functie.

Maar hoe verschilt dit van parameters gemarkeerd als in uit? Rechts. Dat is precies wat velen van ons zich afvragen en het is de motivatie om variabele parameters uit de taal te verwijderen.

Vanuit het perspectief van de functie is er geen verschil, dat wil zeggen dat de functie een veranderbare lokale kopie van de waarde van de parameter ontvangt. Zoals de naam echter aangeeft, is een parameter gemarkeerd als in uit schrijft zijn waarde terug naar de oorspronkelijke variabele.

Om verwarring te voorkomen, var parameters zijn niet langer beschikbaar in Snel 3. Gelukkig, in uit parameters moeten blijven.

Over dat gesproken in uit parameters, in Swift 3, de in uit sleutelwoord is geïntegreerd in de type-syntaxis van functieparameters. Bekijk de volgende voorbeelden om deze wijziging beter te begrijpen.

// Swift 2 func combineStrings (eerste in: String, tweede: String) // ... // Swift 3 func combineStrings (eerste: inout String, tweede: String) // ...

Impliciet Tuple Splat-gedrag

Hoewel Swift nog erg jong is, zijn er veel functies die behoorlijk geavanceerd zijn. Wist u dat u een tuple aan een functie kunt doorgeven in plaats van een lijst met parameters? Het is echter niet nodig om te juichen. Deze functie wordt in Swift 3 verwijderd.

// Pass Argumenten als afzonderlijke argumenten laten zien = UIView () laat configuratie = Configuratie () setupView (bekijk, withConfiguration: configuration) // Pass Argumenten als onderdeel van Tuple laat tuple = (bekijk, withConfiguration: configuration) setupView (tuple)

Chris Lattner verwijst naar dit gedrag als "schattig" in zijn voorstel om de functie te verwijderen. Hoewel dit gedrag van tijd tot tijd nuttig kan zijn, lijkt het nogal wat gevolgen te hebben. De reden om dit voorstel bijeen te brengen, is het belangrijkste doel van het kernteam te benadrukken, door de syntaxis en de API van de taal te vereenvoudigen.

Ik kan zien hoe deze functie er aanvankelijk goed uitzag, maar naarmate de taal groeide, ingewikkelder en meer mensen begonnen ermee te werken. Functies als deze voegen beperkte waarde toe aan de taal in ruil voor wat een lijst met complicaties lijkt te zijn , inclusief prestatieproblemen tijdens de compilatie en complexiteit met de typecontrole die kan worden vermeden door de functie weg te laten.

Wat is de deal met Swift 2.3?

Vorige week schreef ik over Xcode 8. In dat artikel vermeldde ik dat Xcode 8 zowel Swift 2.3 als Swift 3 ondersteunt. Maar wat is Swift 2.3 en hoe is het te vergelijken met Swift 2.2?

Swift 2.3 is een kleine maar belangrijke update voor Swift. Het belangrijkste verschil met Swift 2.2.1, de versie die is opgenomen in Xcode 7.3.1, is compatibiliteit met de SDK's voor de nieuwe besturingssystemen van Apple, iOS 10, tvOS 10, watchOS 3 en macOS Sierra (10.12).

Dit betekent dat je tegen de nieuwe SDK's kunt gebruiken en bouwen zonder de sprong naar Swift 3 te maken. Met Xcode 8 kun je apps indienen bij de App Store met Swift 2.3 of Swift 3. Het Swift-team weet en begrijpt dat de migratie naar Swift 3 heeft een aanzienlijke impact op bestaande projecten die Swift omvatten. Swift 2.3 zorgt ervoor dat u uw projecten kunt migreren wanneer u dat wilt.

Hulpmiddelen

Wat ik ook leuk vind aan het Swift-project, is dat de tools naast de taal worden ontwikkeld. Dit betekent dat de tools ook een substantiële update krijgen als Swift 3 later dit jaar wordt uitgebracht.

Documentatie

Tijdens de WWDC hebben we al een glimp gezien van de wijzigingen die in de documentatie zijn aangebracht. Hoewel dit misschien triviaal lijkt, heb je er wel eens over nagedacht hoeveel tijd je besteedt aan het bladeren door de documentatie? Ik heb een zwak voor dit soort details en waardeer de inspanningen die het team heeft geleverd om de documentatie toegankelijker te maken. De veranderingen zijn nog dramatischer in Xcode 8, zoals ik vorige week schreef.

Xcode

Voorlopig gebruiken de overgrote meerderheid van Swift-ontwikkelaars Xcode als hun werkpaard. Dit kan in de toekomst veranderen naarmate de taal meer grip krijgt op andere platforms. Had Google geen plannen om Swift te gebruiken op Android?

In Xcode 8 is de integratie van Swift veel verbeterd. Navigeren door de standaardbibliotheek is bijvoorbeeld meer intuïtief. In een van de sessies van WWDC 2016 illustreert Ewa Matejska hoe de gesynthetiseerde interfaces nu intuïtiever en gemakkelijker te begrijpen zijn. Dit maakt het bladeren door de standaardbibliotheek minder afschrikwekkend.

Dit brengt ons bij compilatie en optimalisatie. Je hebt misschien al gehoord van de volledige module-optimalisatie. Deze functie is nu standaard ingeschakeld in Xcode. Het heeft invloed op de prestaties van de app en Apple beveelt aan om deze functie in te schakelen tijdens de productie. Als u meer wilt weten over de volledige module-optimalisatie, raad ik aan dit artikel van Keith Harrison te lezen.

Hoewel de volledige module-optimalisatie de compilatietijd verhoogt wanneer u voor het eerst een project bouwt, zijn de resultaten meer dan de moeite waard. Latere builds hebben minder impact dankzij de incrementele compilatie.

Conclusie

Swift 3 is een belangrijke mijlpaal voor iedereen die bij de Swift-gemeenschap betrokken is. Hoewel niemand van het breken van veranderingen houdt, wordt de richting die de taal volgt steeds duidelijker, waardoor het platform robuuster wordt en klaar is voor toekomstige wijzigingen zonder de compatibiliteit van de bron aan te tasten.

In dit artikel belichtte ik enkele van de belangrijkste wijzigingen die u kunt verwachten in Swift 3. Voor een uitgebreide lijst van de wijzigingen raad ik u aan de migratiehandleiding op de Swift-website te bezoeken..

Je kunt ook het Swift-evolutieproject op GitHub bezoeken om meer te lezen over de voorstellen die zijn aanvaard en de voorstellen waaraan nog wordt gewerkt. Wees niet bang. De voorstellen zijn vaak gemakkelijk te begrijpen. In feite is het doel van het Swift-evolutieproject dat iedereen aan de discussie kan toevoegen. Wat houdt je tegen?