Início / coding / Perguntas / 79599296
Accepted
HL666
Asked: 2025-04-30 06:55:21 +0800 CST

Comportamento estranho na verificação de metatipos Swift

  • 772

Estou brincando com a resposta desta questão: Como testar se uma variável genérica é do tipo AnyObject

Essa solução parece não funcionar mais. Tenho este código:

public struct ObjectHashable<T>: Hashable {
  
  public let object: T
  
  public init(object: T) {
    
    let t1 = type(of: object)
    let b1 = t1 is AnyClass
    print(t1) // Plugin
    print(b1) // false
    
    let t2 = T.self
    let b2 = t2 is AnyClass
    print(t2) // Plugin 
    print(b2) // false
    
    let t3 = Mirror(reflecting: object).subjectType 
    let b3 = t3 is AnyClass 
    print(t3) // P
    print(b3) // true 

    self.object = object
    
  }
  
  public static func ==(lhs: Self, rhs: Self) -> Bool {
    return true
  }
  
  public func hash(into hasher: inout Hasher) {
  }
}

protocol Plugin: AnyObject {}
class P: Plugin {}

typealias PluginHashable = ObjectHashable<Plugin>

PluginHashable(object: P())

Esse é um comportamento surpreendente.

1.

let t1 = type(of: object)

type(of:)deveria retornar o tipo dinâmico, que é P, não Plugin. Mas obtive "Plugin" impresso.

2.

let b1 = t1 is AnyClass

Não deveria ser verdade, já que t1 é um tipo de referência? (com base na resposta aqui: Como testar se uma variável genérica é do tipo AnyObject )

3.

let t2 = T.self

Isso imprime Plugin, o que faz sentido, porque eu Plugincoloquei<>

4.

let b2 = t2 is AnyClass

Isso é falso, mas acho que deveria ser verdade pelo mesmo motivo

5.

    let t3 = Mirror(reflecting: object).subjectType // P

Isso imprime P, o que faz sentido

6.

    let b3 = t3 is AnyClass // true

Isso é verdade, o que faz sentido. Mas por que é diferente dos outros dois casos?

swift

1 respostas

  1. Best Answer

    Esse comportamento inesperado é documentado na seção chamada Encontrando o Tipo Dinâmico em um Contexto Genérico :

    Normalmente, você não precisa estar ciente da diferença entre metatipos concretos e existenciais, mas a chamada type(of:)pode produzir resultados inesperados em um contexto genérico com um parâmetro de tipo vinculado a um protocolo. Em um caso como este, onde um parâmetro genérico Testá vinculado a um protocolo P, o parâmetro de tipo não é estaticamente conhecido como um tipo de protocolo no corpo da função genérica. Como resultado, type(of:)pode produzir apenas o metatipo concreto P.Protocol.

    No seu exemplo, Pseria o Pluginprotocolo. Para expandir a explicação na documentação, a type(of:)função possui algumas regras de verificação de tipo incomuns .

    Ou seja, se o compilador perceber que seu parâmetro é um tipo existencial, ele permitirá que o tipo de toda a type(of:)expressão seja um metatipo concreto, que de outra forma seria um tipo totalmente não relacionado ao metatipo do tipo existencial.

    No ObjectHashableentanto, o tipo de objecté T. O compilador não sabe que this será vinculado ao tipo existencial any Pluginposteriormente, portanto, não aplica esta regra especial de verificação de tipo para tipos existenciais. type(of: object)é basicamente equivalente a T.self.

    O comportamento de type(of:)foi alterado para funcionar assim neste commit , o que aconteceu depois que a resposta vinculada foi publicada.

    Como a documentação sugere, converter objectpara um tipo existencial (o mais fácil é Any) antes de colocá-lo em type(of:)funcionaria como esperado.

    type(of: object as Any) is AnyClass // true

    Em relação a 2 e 4, não há muito o que explicar. Eles simplesmente não são classes. Só porque o Pluginé restrito por classe não significa que o tipo existencial any Pluginseja uma classe. Tipos existenciais são muito diferentes de tipos concretos. A SE-0335 propôs que todos os tipos existenciais fossem prefixados com anypara destacar essa diferença.

    [...]

    Apesar dessas implicações significativas e frequentemente indesejáveis, os tipos existenciais têm uma grafia mínima. Sintaticamente, o custo de usá-los é oculto, e a grafia semelhante à das restrições genéricas tem levado muitos programadores a confundir tipos existenciais com genéricos. Na realidade, a necessidade do dinamismo que eles proporcionam é relativamente rara em comparação com a necessidade de genéricos, mas a linguagem torna os tipos existenciais muito fáceis de serem acessados, especialmente por engano. O custo de usar tipos existenciais não deve ser oculto, e os programadores devem optar explicitamente por essa semântica.

    [...]

    Proponho tornar os tipos existenciais sintaticamente explícitos na linguagem usando a anypalavra-chave . Esta proposta introduz a nova sintaxe no modo de linguagem Swift 5, e essa sintaxe deverá ser obrigatória para tipos existenciais em um futuro modo de linguagem.

    • 1

relate perguntas