Swift 4, o que vem por aí

Esperado para o final de 2017, o Swift 4 tem como foco estabilizar a linguagem, tanto no código fonte quanto no nível da ABI. As novas funcionalidades incluem melhorias no generics e no modelo de memória inspirado no Rust/Cyclone.

O desenvolvimento do Swift 4 será dividido em dois estágios. O primeiro estágio incluirá todas funcionalidades que são necessárias para estabilizar a ABI (Application Binary Interface) do Swift assegurando a compatibilidade de código com o Swift 3. O segundo estágio, que ainda não está definido, também pode conter novas funcionalidades para a linguagem, desde que não altere a ABI dos recursos existentes na linguagem ou quebre a ABI para a biblioteca padrão.

Compatibilidade de código

A exigência de compatibilidade de código é fundamental, embora ter uma linguagem estável possa prejudicar a capacidade da linguagem evoluir. Para permitir o progresso rápido e ao mesmo tempo garantir a compatibilidade, a equipe do Swift irá estender o atributo existente @available para indicar a disponibilidade da funcionalidade não somente relativa a uma plataforma ou versão de sistema operacional, mas também relativo as versões do Swift.

Por exemplo, é possível declarar que uma API está obsoleta no Swift 3.1 da seguinte forma:

@available(swift, obsoleted: 3.1)
class Foo {
  //...
}

Estabilidade da ABI

Para estabilizar a ABI será necessário estabelecer as bases para novos recursos a serem adicionados, uma funcionalidade conhecida como resiliência, que fornecerá um caminho para as APIs públicas evoluírem garantindo a estabilidade da ABI. Isso pode ser conseguido por exemplo, tornando explícito quais partes das APIs poderão mudar sem quebrar a ABI, eliminando o problema chamado fragile base class que pode ocorrer em algumas linguagens orientadas a objeto.

Por outro lado, estabilizar a ABI requer eliminar deficiências existentes na linguagem. Uma série de melhorias já foi identificada, tais como:

• conditional conformances, que expressa a noção de que um tipo genérico estará de acordo com um protocolo em específico somente quando seus argumentos de tipo atender a certos requisitos. Um exemplo é uma coleção de Array, que pode implementar o protocolo Equatable somente se os elementos são Equatable:

extension Array: Equatable where Element: Equatable {
	  static func ==(lhs: Array, rhs: Array) -> Bool { ... }
	}

• requisitos de protocolo recursivo, permite que um tipo associado esteja de acordo com um protocol aninhando. Por exemplo, um Subsequence deve ser Sequence, uma vez que o Swift 4 permitirá a seguinte definição:

protocol Sequence {
	  associatedtype Iterator : IteratorProtocol
	  ...
	  associatedtype SubSequence : Sequence   // currently ill-formed, but should be possible
	}

• cláusula where para tipos associados, que trará o expressivo poder do where, já disponível com os parâmetros de tipo genérico, para tipos associados. Por exemplo:

protocol Sequence {
	  associatedtype Iterator : IteratorProtocol
	  associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element
	  ...
	}

Finalmente, uma grande parte do trabalho será na definição de um modelo de memória inspirado no Cyclone e Rust. O conceito de gerenciamento de memória tem como base o conceito de propriedade da entidade, que pode ser movido ou emprestado para rastrear quem é o responsável pelo uso e desalocação da entidade. Isto está associado com uma noção de ciclo de vida para evitar referências oscilando quando uma entidade estiver finalmente desalocada.

O dialeto C do Cyclone, que não está mais em desenvolvimento, usou um modelo de gerenciamento de memória com base em região, na qual cada entidade é atribuída para uma região, deste modo aperfeiçoando a memória em relação a alocação/desalocação e no suporte à detecção de entidades desalocadas. Estender o modelo de gerenciamento de memória do Swift será muito útil para os desenvolvedores e em todos os casos no qual desempenho determinista é um altamente desejável. Este esforço previsivelmente se estenderá além dos limites da fase 1, no qual o objetivo é ter um projeto abrangente para entender como a ABI será mudada.