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 p
osed a mechanism encompassing all protocols, not
>>>>> just Equatable and Hashable, to handle the issue of mistakenly believing
>>>>> you’re overriding a default implementation. Having trouble finding it at
>>>>> the moment.
>>>>
a mechanism encompassing all protocols, not
>>> just Equatable and Hashable, to handle the issue of mistakenly believing
>>> you’re overriding a default implementation. Having trouble finding it at
>>> the moment.
>>
>> Is this what you’re thinking of?
>>
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
-1
I love the desire for consistency in this proposal, but it brings up two issues:
1. Swift’s take on standalone functions vs member functions: As Swift has
progressed, it seems to have adopted a preference (which I like) in favor of
members over functions that just take arguments. I think tha
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 a
