Share
Du vet säkert att Swift 3 kommer senare i år. Det är den första release som innehåller det svåra arbetet i en fantastisk gemenskap. Dussintals förslag lämnades sedan Apple öppnade Swift i 2015 och dussintals accepterades efter noggrann övervägning av kärnteamet. I den här artikeln tar vi en titt på några viktiga förändringar i Swift 3.
Kärnteamet har ett mycket tydligt mål i åtanke med frisläppandet av Swift 3, vilket skapar en solid grund för Swift-programmeringsspråket. Vid WWDC 2016 betonade Chris Lattner att Swift 3 introducerar en rad brytningsändringar med avsikt att få de grundläggande rättigheterna. Det är det vanliga temat för den kommande versionen. Det innebär att bryta befintliga funktioner, ta bort vissa funktioner och förbättra grunden för språket.
Swift evolution-projektet har varit en sann succeshistorie för alla som är involverade i Swift community. Engagemanget har varit enormt och resultatet är Swift 3. Apple är transparent om frisläppandet och snapshots av Swift 3 är tillgängliga från Swift hemsida och ingår i Xcode 8, som är i beta vid skrivningstidpunkten..
Swift 3-utgåvan fokuserar inte bara på Swift-programmeringsspråket, det innehåller också väsentliga ändringar av verktygsredskapet, standardbiblioteket och språkets interoperabilitet med kakao. Kom ihåg att Swift är mer än ett språk. När vi pratar om Swift tänker vi allmänt bara på språket, men det innehåller också standardbiblioteket och paketchefen.
Om du har arbetat med Swift vet du att att migrera en kodbas från en version till en annan är ingen liten prestation. Tyvärr kommer migreringen av ett projekt till Swift 3 inte att vara annorlunda.
Med det sagt är Swift 3: s främsta mål att se till att övergången från Swift 3 till framtida versioner av språket inte kommer att bli så. Källkompatibilitet är en nyckelpunkt för Swift 3.
Swift var designat för att vara ett modernt programmeringsspråk, men det var lika viktigt att skapa ett språk som såg bra ut och var ... bra ... awesome. Med Swift 3 fortsätter laget att "optimera språket för awesomeness" som Chris Lattner uttrycker det.
Medan det finns många brottförändringar, är nettoresultatet ett språk som känns och ser bra ut. Swift 3 är en glädje att använda. Ändringarna till Core Graphics och Grand Central Dispatch, som vi diskuterar på ett ögonblick, är fina exempel.
Något om hur fantastisk Swift är och hur mycket mer fantastisk Swift 3 kommer att vara. I resten av denna artikel vill jag fokusera på några av de viktiga förändringarna som introducerades i Swift 3. Tänk på att Swift 3 fortsätter att utvecklas tills den officiella utgåvan senare i år.
Många tid och energi spenderades på att förbättra API i Swift-språket. Ändringarna är signifikanta, det kan inte nekas. Men resultatet är väldigt, väldigt trevligt. Med Swift 3 syftar kärnteamet till ett API som fokuserar på läsbarhet och tillgänglighet.
Medan många av oss har blivit vana vid Objective-C-verkligheten, tar det nya Swift API ett annat tillvägagångssätt genom att bara betona och fokusera på de väsentliga. Ta en titt på följande exempel på Swift 2.2.1. Detta exempel ska se väl om du har tillbringat tid med Swift ... eller Objective-C.
parentViewController.presentViewController (newViewController, animerad: true, completion: nil)
I Swift 3 ser denna kodbit lite annorlunda ut som du kan se nedan.
parentViewController.present (newViewController, animerad: true, completion: nil)
Swift community insåg att det inte finns något behov av att inkludera en referens till vad som håller på att presenteras eftersom den informationen redan ingår i den första parametern. Som ett resultat blir metodnamnet mer läsbart och mer koncist. En bestämd förbättring om du frågar mig.
Detta är en vanlig tråd i Swift 3. Flera av de förslag som godkändes och inkluderades i Swift 3 fokuserar på förenkling och avlägsnande av cruft från språket. Swift API var initialt starkt påverkat av Objective-C's verbala natur. Läsbarhet är bra, men Swift 3 skär tillbaka på verbositet utan att äventyra läsbarheten.
Swift community anser att utformningen av ett API alltid bör ta hänsyn till API: n och det är tydligt synligt i de förändringar som introduceras i Swift 3. Jag är säker på att du håller med om att det uppgraderade API-seriet och läser-stor.
En annan viktig förändring som många utvecklare välkomnar är den konsekventa signaturen av funktion och metoder genom att inkludera den första parameterns etikett som standard. Så här ser en typisk funktion ut i Swift 2.2.1. Som standard utelämnas den första parametermärken när funktionen påkallas.
func setupView (visa: UIView, withConfiguration konfiguration: Configuration) // ... setupView (visa, med konfiguration: konfiguration)
Det är inte längre sant i Swift 3. Den första parametern ges inte längre en särskild behandling, vilket är en mycket välkommen förändring.
func setupView (visa: UIView, withConfiguration konfiguration: Configuration) // ... setupView (visa: visa, med konfiguration: konfiguration)
På grund av denna ändring kan du ytterligare förbättra ovanstående exempel genom att utesluta referensen till vyn i funktionsnamnet.
func setup (visa: UIView, med konfiguration konfiguration: konfiguration) // ... setup (view: view, withConfiguration: configuration)
Att arbeta med C-API-er i Swift har alltid tittat och känt klumpigt. Core Graphics-funktioner, till exempel, importeras som globala funktioner, vilket inte är en bra lösning och som ett resultat, använder Core Graphics i Swift inte bra.
Detsamma gäller för Grand Central Dispatch. I nästa exempel använder vi Grand Central Dispatch för att asynkront skicka en uppgift till en bakgrundskö.
dispatch_async (dispatch_get_global_queue (DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) // ...
I Swift 3 känns API mycket mer som ett inbyggt Swift API. Funktioner importeras som metoder, vilket resulterar i följande syntax i Swift 3.
DispatchQueue.global (attribut: .qosBackground) .async // ...
Swift community kom också överens om att ett antal funktioner skulle avlägsnas, varav några har gett upphov till några uppvärmda diskussioner. Jag vill påpeka fyra av dem.
Accentsconagua
för LoopsSer det här känt för dig?
för (var i = 0; i < 5; i++) print(i)
C-stil för Slingor är inte längre tillgängliga i Swift 3. Vänta. Vad? Varför? Det är en mycket bra fråga. Du kan läsa förslaget som skickats av Erica Sadun på GitHub. Detta leder oss till nästa kontroversiella förändring.
++ och --Snart efter öppet inköp Swift, lämnade Chris Lattner, skaparen av Swift, ett förslag om att ta bort inkrement och minskning av operatörer från språket. I sitt förslag nämner han att dessa operatörer tillsattes, "utan stor hänsyn", tidigt i utvecklingen av Swift. Att städa upp Swift API och undvika förvirring, ++ och -- är inte längre tillgängliga i Swift.
var a = 0 a++
Men gör inte panik. Lösningen är enkel. Inget behov av att skrämma.
var a = 0 a + = 1
var parametrarOm du är bekant med funktioner i Swift vet du att parametrarna för en funktion är standard som standard. Du kan ändra detta beteende genom att lägga ut ett parameternamn med var nyckelord. För variabla parametrar skickas en variabel kopia av parametern till funktionen.
Men hur skiljer det sig från parametrar markerade som in ut? Höger. Det är precis vad många av oss har undrat och det är motivationen att ta bort variabla parametrar från språket.
Ur funktionens perspektiv är det ingen skillnad, det vill säga, funktionen får en mutabel lokal kopia av parameterns värde. Som namnet antyder är emellertid en parameter markerad som in ut skriver sitt värde tillbaka till den ursprungliga variabeln.
För att undvika förvirring, var parametrar är inte längre tillgängliga i Swift 3. Lyckligtvis, in ut parametrar är här för att stanna.
På tal om in ut parametrar, i Swift 3, the in ut nyckelordet är integrerat i typ-syntaxen för funktionsparametrar. Ta en titt på följande exempel för att bättre förstå denna förändring.
// Swift 2 func combineStrings (inout först: String, second: String) // ... // Swift 3 func combineStrings (första: inString, andra: String) // ...
Även om Swift fortfarande är väldigt ung, finns det många funktioner som är ganska avancerade. Visste du att du kan skicka en tupel till en funktion i stället för en lista med parametrar? Det är dock inte nödvändigt att jubla. Den här funktionen kommer att tas bort i Swift 3.
// Pass Arguments As Separate Arguments Let View = UIView () Låt konfiguration = Konfiguration () setupVisa (visa, med Konfiguration: konfiguration) // Pass Arguments Som del av Tuple Låt Tuple = (visa, medConfiguration: konfiguration) setupView (tuple)
Chris Lattner hänvisar till detta beteende som "söt" i sitt förslag om att ta bort funktionen. Även om detta beteende kan vara användbart från tid till annan, verkar det ha en hel del konsekvenser. Anledningen till att detta förslag tas upp är att lyfta fram huvudmålet för kärnteamet, förenkla syntaxen och språkets API.
Jag kan se hur denna funktion såg snygg ut först, men eftersom språket växte, blev komplexitet och fler började använda det, sätter funktioner som detta på ett begränsat värde till språket i utbyte mot vad som verkar vara en lista över komplikationer , inklusive prestandaproblem under sammanställningen och komplexiteten till typkontrollen som kan undvikas genom att utelämna funktionen.
Förra veckan skrev jag om Xcode 8. I den artikeln nämnde jag att Xcode 8 stöder både Swift 2.3 och Swift 3. Men vad är Swift 2,3 och hur jämför det med Swift 2.2?
Swift 2.3 är en mindre men viktig uppdatering till Swift. Huvudskillnaden med Swift 2.2.1, versionen som ingår i Xcode 7.3.1, är kompatibilitet med SDK: erna för Apples nya operativsystem, iOS 10, tvOS 10, watchOS 3 och macOS Sierra (10.12).
Det innebär att du kan använda och bygga mot de nya SDK-enheterna utan att hoppa till Swift 3. Med Xcode 8 kan du skicka in applikationer till App Store med Swift 2.3 eller Swift 3. Swift-teamet vet och förstår att överflyttningen till Swift 3 har en betydande inverkan på befintliga projekt som inkluderar Swift. Swift 2.3 gör att du kan migrera dina projekt när du passar dig.
Vad jag också tycker om Swift-projektet är att verktygen utvecklas bredvid språket. Det betyder att verktygen också får en väsentlig uppdatering när Swift 3 släpps senare i år.
Under WWDC såg vi redan en inblick i de ändringar som gjorts i dokumentationen. Även om det här kan tyckas trivialt, har du någonsin tänkt på hur mycket tid du spenderar på att bläddra i dokumentationen? Jag har en mjuk plats för detaljer som detta och uppskattar den ansträngning laget har gjort för att göra dokumentationen mer tillgänglig. Ändringarna är ännu mer dramatiska i Xcode 8 som jag skrev förra veckan.
För närvarande använder de flesta Swift-utvecklarna Xcode som sin arbetshäst. Det kan komma att förändras i framtiden, eftersom språket får traktion på andra plattformar. Inte Google har planer på att använda Swift på Android?
I Xcode 8 är integrationen av Swift mycket förbättrad. Navigering av standardbiblioteket är till exempel mer intuitivt. I en av sessionerna i WWDC 2016 illustrerar Ewa Matejska hur de syntetiserade gränssnitten nu är mer intuitiva och lättare att förstå. Detta gör att webbläsaren blir mindre skrämmande.
Detta leder oss till kompilering och optimering. Du kanske har hört talas om hela moduloptimering. Den här funktionen är nu aktiverad som standard i Xcode. Det påverkar programmets prestanda och Apple rekommenderar att den här funktionen är aktiverad i produktion. Om du vill lära dig mer om optimering av hela modulen rekommenderar jag att du läser den här artikeln av Keith Harrison.
Medan hela moduloptimering ökar kompileringstiden när du först bygger ett projekt, är resultaten mer än värda det. Efterföljande byggnader påverkas mindre tack vare inkrementell sammanställning.
Swift 3 är en viktig milstolpe för alla som är involverade i Swift community. Även om ingen tycker om att bryta förändringar, blir språket i riktning tydligare, vilket gör plattformen mer robust och redo för framtida förändringar utan att kompromissa med källkompatibiliteten.
I denna artikel markerade jag några av de viktigaste ändringarna som du kan förvänta dig i Swift 3. För en omfattande lista över ändringarna uppmanar jag dig att besöka migrationsguiden på Swift webbplats.
Du kan också besöka Swift evolutionprojektet på GitHub för att läsa mer om de förslag som har godkänts och de som fortfarande arbetar. Var inte rädd. Förslagen är ofta lätta att förstå. I själva verket är målet för Swift evolution-projektet för alla att kunna lägga till diskussionen. Vad hindrar dig?
