Chris Lattner wrote:
> Also, if I were to nitpick your argument a bit, it isn’t true that the
> protocol knows “nothing" about the type anyway, because the protocol has
> access to self. The default implementation could conceptually use reflection
> to access all the state in the type: we’re
org>> wrote:
>>>>>
>>>>> I could have sworn that this sort of issue came up on this list earlier
>>>>> this year… Someone proposed a mechanism encompassing all protocols, not
>>>>> just Equatable and Hashable, to handle the issue o
aving trouble finding it at
>>> the moment.
>>
>> Is this what you’re thinking of?
>> https://github.com/apple/swift-evolution/pull/724
>> <https://github.com/apple/swift-evolution/pull/724>
>>
>> -Chris
>>
>>
>>
&g
If I understand it, merely adding Equatable or Hashable will cause the compiler
to synthesize requirements. This syntax opens up the possibility for errors:
struct Snort: Hashable {
static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}
In the above example, the programmer meant to
First post to Swift evolution, please bear with me: the following is a bit
wild, but something to think about for the future, maybe.
Swift had three, and will now have four levels of scoping. In the future, might
there be five? A scope that spans a limited set of modules, or a scope that
only
