Share
Du vet sikkert at Swift 3 kommer senere i år. Det er den første utgivelsen som inkorporerer det harde arbeidet til et fantastisk samfunn. Tusenvis av forslag ble sendt inn siden Apple åpnet Sør-Swift i 2015, og dusinvis ble akseptert etter nøye vurdering av kjerneteamet. I denne artikkelen tar vi en titt på noen av de viktige endringene i Swift 3.
Kjerneteamet har et veldig klart mål i tankene med utgivelsen av Swift 3, og skaper et solid grunnlag for Swift programmeringsspråket. På WWDC 2016 understreket Chris Lattner at Swift 3 introduserer en rekke brytende endringer med sikte på å få grunnleggende rett. Det er det vanlige temaet for den kommende utgivelsen. Dette betyr å bryte eksisterende funksjoner, fjerne noen funksjoner og forbedre grunnlaget for språket.
Swift-utviklingsprosjektet har vært en sann suksesshistorie for alle som er involvert i Swift-samfunnet. Forlovelsen har vært enorm, og resultatet er Swift 3. Apple er gjennomsiktig om utgivelsesprosessen og snapshots av Swift 3 er tilgjengelig fra Swift nettside og inngår i Xcode 8, som er i beta ved skrivingstidspunktet..
Swift 3-utgivelsen fokuserer ikke bare på Swift programmeringsspråket, det inkluderer også vesentlige endringer i verktøykjeden, standardbiblioteket og språks interoperabilitet med kakao. Husk at Swift er mer enn et språk. Når vi snakker om Swift, tenker vi generelt bare på språket, men det inkluderer også standardbiblioteket og pakkebehandleren.
Hvis du har jobbet med Swift, vet du at å migrere en kodebase fra en versjon til en annen er ingen liten prestasjon. Dessverre vil det ikke være annerledes å migrere et prosjekt til Swift 3.
Når det er sagt, er det primære målet med Swift 3 å sørge for at overgangen fra Swift 3 til fremtidige versjoner av språket ikke vil være slik. Kildekompatibilitet er et sentralt fokuspunkt for Swift 3.
Swift ble designet for å være et moderne programmeringsspråk, men det var like viktig å lage et språk som så fint ut og var ... vel ... fantastisk. Med Swift 3 fortsetter teamet å "optimalisere språket for awesomeness" som Chris Lattner legger det.
Mens det er mange bryteendringer, er nettoresultatet et språk som føles og ser bra ut. Swift 3 er en glede å bruke. Endringene til Core Graphics og Grand Central Dispatch, som vi diskuterer på et øyeblikk, er gode eksempler.
Nok om hvor fantastisk Swift er og hvor mye mer fantastisk Swift 3 vil være. I resten av denne artikkelen vil jeg fokusere på noen av de viktigste endringene som ble introdusert i Swift 3. Husk at Swift 3 fortsetter å utvikle seg til den offisielle utgivelsen senere i år.
Mye tid og energi ble brukt på å forbedre API i Swift-språket. Endringene er signifikante, det er ikke nektet det. Men resultatet er veldig, veldig fint. Med Swift 3 tar kjernelaget seg for en API som fokuserer på lesbarhet og tilgjengelighet.
Selv om mange av oss har blitt vant til objektiv-C's verbose, tar den nye Swift API en annen tilnærming ved bare å vektlegge og fokusere på de viktigste. Ta en titt på følgende eksempel på Swift 2.2.1. Dette eksemplet skal se kjent hvis du har brukt litt tid med Swift ... eller Objective-C.
parentViewController.presentViewController (newViewController, animert: true, fullføring: null)
I Swift 3 ser dette kodestykket litt annerledes ut som du kan se nedenfor.
parentViewController.present (newViewController, animert: true, fullføring: null)
Swift-samfunnet innså at det ikke er behov for å inkludere en referanse til hva som skal presenteres siden denne informasjonen allerede er inkludert i den første parameteren. Som et resultat blir metodenavnet mer lesbart og mer konsistent. En klar forbedring hvis du spør meg.
Dette er en felles tråd i Swift 3. Flere av forslagene som ble akseptert og inkludert i Swift 3 fokuserer på forenkling og fjerning av cruft fra språket. Swift API ble i utgangspunktet sterkt påvirket av Objective-C's verbose natur. Lesbarhet er flott, men Swift 3 kuttes tilbake på skjønnhet uten å svekke lesbarheten.
Swift-fellesskapet er av den oppfatning at utformingen av en API alltid bør ta hensyn til bruk av API-en, og det er tydelig synlig i endringene som introduseres i Swift 3. Jeg er sikker på at du er enig i at det reviderte API-utseendet og leser-stor.
En annen viktig forandring mange utviklere velkommen er den konsekvente signaturen til funksjon og metoder ved å inkludere den første parameteretiketten som standard. Slik ser en typisk funksjon ut i Swift 2.2.1. Som standard blir den første parameteretiketten utelatt når funksjonen er påkalt.
func setupView (se: UIView, withConfiguration konfigurasjon: Konfigurasjon) // ... setupView (view, withConfiguration: configuration)
Det er ikke lenger sant i Swift 3. Den første parameteren er ikke lenger gitt en spesiell behandling, noe som er en veldig velkommen endring.
func setupView (se: UIView, withConfiguration konfigurasjon: Konfigurasjon) // ... setupView (view: view, withConfiguration: configuration)
På grunn av denne endringen kan du ytterligere forbedre eksemplet ovenfor ved å utelate referansen til visningen i funksjonsnavnet.
func setup (visning: UIView, withConfiguration konfigurasjon: Konfigurasjon) // ... setup (view: view, withConfiguration: configuration)
Arbeid med C APIs i Swift har alltid sett og følt clunky. Core Graphics-funksjoner, for eksempel, blir importert som globale funksjoner, noe som ikke er en god løsning, og som følge av dette, bruker Core Graphics i Swift ikke bra.
Det samme gjelder Grand Central Dispatch. I det neste eksemplet bruker vi Grand Central Dispatch til å asynkront sende en oppgave til en bakgrunnskø.
dispatch_async (dispatch_get_global_queue (DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) // ...
I Swift 3 føles API mye mer som en innfødt Swift API. Funksjoner importeres som metoder, noe som resulterer i følgende syntaks i Swift 3.
DispatchQueue.global (attributter: .qosBackground) .async // ...
Det swift samfunnet ble også enige om fjerning av en rekke funksjoner, hvorav noen har utløst noen oppvarmede diskusjoner. Jeg vil gjerne påpeke fire av dem.
Accentsconagua
til LoopsSer dette ut til deg?
for (var i = 0; i < 5; i++) print(i)
C-stil til sløyfer er ikke lenger tilgjengelige i Swift 3. Vent. Hva? Hvorfor? Det er et veldig godt spørsmål. Du kan lese forslaget, sendt av Erica Sadun, på GitHub. Dette bringer oss til neste kontroversielle forandring.
++ og --Snart etter åpent sourcing Swift, sendte Chris Lattner, skaperen av Swift, et forslag om å fjerne økningen og redusere operatørene fra språket. I hans forslag nevner han at disse operatørene ble lagt til, "uten mye hensyn", tidlig i utviklingen av Swift. Å rydde opp Swift API og unngå forvirring, ++ og -- er ikke lenger tilgjengelig i Swift.
var a = 0 a++
Ikke vær panikk, skjønt. Løsningen er enkel. Du trenger ikke å bekymre deg.
var a = 0 a + = 1
Var parametereHvis du er kjent med funksjoner i Swift, vet du at parametrene til en funksjon er standard som standard. Du kan endre denne oppførselen ved å forhåndsbeide et parameternavn med Var søkeord. For variable parametere sendes en variabel kopi av parameteren til funksjonen.
Men hvordan er det forskjellig fra parametere merket som inout? Ikke sant. Det er akkurat det mange av oss har lurt på, og det er motivasjonen for å fjerne variable parametere fra språket.
Fra funksjonens perspektiv er det ingen forskjell, det vil si, funksjonen mottar en gjenkjennelig lokal kopi av parameterens verdi. Som navnet antyder, men en parameter merket som inout skriver verdien tilbake til den opprinnelige variabelen.
For å unngå forvirring, Var Parametere er ikke lenger tilgjengelige i Swift 3. Heldigvis, inout parametere er her for å bli.
Apropos inout parametere, i Swift 3, the inout Søkeordet er integrert i typen syntaks av funksjonsparametere. Ta en titt på følgende eksempler for bedre å forstå denne endringen.
// Swift 2 Func CombStrings (første: String, Second: String) // ... // Swift 3 Func CombStrings (Første: Inout String, Second: String) // ...
Selv om Swift fortsatt er veldig ung, er det mange funksjoner som er ganske avanserte. Visste du at du kan sende en tuple til en funksjon i stedet for en liste over parametere? Det er ikke nødvendig å juble, skjønt. Denne funksjonen vil bli fjernet i Swift 3.
// Pass argumenter som separate argumenter la vise = UIView () la konfigurasjon = Konfigurasjon () setupView (se, med konfigurasjon: konfigurasjon) // Pass argumenter Som del av Tuple la tuple = (se, medConfiguration: konfigurasjon) setupView (tuple)
Chris Lattner refererer til denne oppførselen som "søt" i hans forslag for å fjerne funksjonen. Mens denne virkemåten kan være nyttig fra tid til annen, ser det ut til å ha ganske få konsekvenser. Årsaken til å bringe opp dette forslaget er å markere hovedmålet med kjerneteamet, forenkle syntaksen og språkets API.
Jeg kan se hvordan denne funksjonen så pent ut i begynnelsen, men etter hvert som språket vokste, ble det kompleks, og flere begynte å bruke det, legger funksjoner som dette til å legge til begrenset verdi til språket i stedet for det som synes å være en liste over komplikasjoner , inkludert ytelsesproblemer under kompilering og kompleksitet til typekontrolleren som kan unngås ved å utelate funksjonen.
I forrige uke skrev jeg om Xcode 8. I den artikkelen nevnte jeg at Xcode 8 støtter både Swift 2.3 og Swift 3. Men hva er Swift 2.3 og hvordan sammenligner det med Swift 2.2?
Swift 2.3 er en mindre, men viktig oppdatering til Swift. Hovedforskjellen med Swift 2.2.1, versjonen som er inkludert i Xcode 7.3.1, er kompatibilitet med SDKene for Apples nye operativsystemer, iOS 10, tvOS 10, watchOS 3 og macOS Sierra (10.12).
Dette betyr at du kan bruke og bygge opp mot de nye SDKene uten å hoppe til Swift 3. Med Xcode 8 kan du sende inn applikasjoner til App Store ved hjelp av Swift 2.3 eller Swift 3. Swift-teamet vet og forstår at overføringen til Swift 3 har en betydelig innvirkning på eksisterende prosjekter som inkluderer Swift. Swift 2.3 sørger for at du kan migrere prosjektene dine når du ser det.
Det jeg liker om Swift-prosjektet er at verktøyene er utviklet sammen med språket. Dette betyr at verktøyene også mottar en betydelig oppdatering når Swift 3 slippes senere i år.
Under WWDC så vi allerede et innblikk i endringene i dokumentasjonen. Selv om dette kan virke trivielt, har du noensinne vurdert hvor mye tid du bruker til å bla gjennom dokumentasjonen? Jeg har et mykt sted for detaljer som dette, og setter pris på innsatsen teamet har satt i å gjøre dokumentasjonen mer tilgjengelig. Endringene er enda mer dramatiske i Xcode 8 som jeg skrev i forrige uke.
For nå bruker det store flertallet av Swift-utviklere Xcode som arbeidshest. Dette kan endres i fremtiden da språket får trekkraft på andre plattformer. Har ikke Google planer om å bruke Swift på Android?
I Xcode 8 er integrasjonen av Swift mye bedre. Navigering av standardbiblioteket, for eksempel, er mer intuitivt. I en av sesjonene i WWDC 2016 illustrerer Ewa Matejska hvordan de syntetiserte grensesnittene nå er mer intuitive og enklere å forstå. Dette gjør det enklere å bla gjennom standardbiblioteket.
Dette bringer oss til kompilering og optimalisering. Du har kanskje hørt om hele moduloptimalisering. Denne funksjonen er nå aktivert som standard i Xcode. Det påvirker programytelsen, og Apple anbefaler at denne funksjonen er aktivert i produksjon. Hvis du vil lære mer om helmoduloptimalisering, anbefaler jeg at du leser denne artikkelen av Keith Harrison.
Mens hele moduloptimalisering øker kompileringstiden når du først bygger et prosjekt, er resultatene mer enn verdt det. Etterfølgende bygg er mindre påvirket takket være inkrementell kompilering.
Swift 3 er en viktig milepæl for alle som er involvert i Swift-fellesskapet. Selv om ingen liker å bryte endringer, er retningen språket blir tydeligere, noe som gjør plattformen mer robust og klar for fremtidige endringer uten at kompromissene mellom kildekompatibilitet.
I denne artikkelen har jeg fremhevet noen av de viktigste endringene du kan forvente i Swift 3. For en omfattende liste over endringene, oppfordrer jeg deg til å besøke overføringsveiledningen på Swift-nettstedet.
Du kan også besøke Swift Evolution-prosjektet på GitHub for å lese mer om forslagene som er akseptert og de som fortsatt jobber med. Ikke vær redd. Forslagene er ofte enkle å forstå. Faktisk er målet for Swift Evolution-prosjektet for alle å kunne legge til diskusjonen. Hva stopper deg?
