If Swift is to be used for serious data handling, might as well learn from the
java early errors and directly go highly optimized intrinsic code for this type
of features: even phones have very good vectorized instructions ... would be
tragic to use run of the mill gereral purpose code instead
On May 31, 2016, at 9:03 AM, Brent Royal-Gordon via swift-evolution
<swift-evolution@swift.org> wrote:
>> I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that
>> automatic conformance can be defined in the language itself and that derived
>> protocol instances don't have to be implemented as compiler intrinsics.
>> That's just not the case. You cannot define something like
>>
>> @auto protocol AutoEquatable : Equatable {
>> ...
>> }
>>
>> because what would you write instead of "..."? Copy Lisp-Macros? Copy
>> Template-Haskell? I don't really need to disagree here, I could just say
>> "good idea, do you want to make a proposal for this?" and then I will never
>> hear again anything from this idea, because no one will be able to write the
>> "detailed design" section of that proposal. (at least, I don't know how to
>> design such a feature; the solution space looks empty to me. there are
>> similar issues with "property behaviors" IMHO, but that's another story.)
>
> Actually, I believe you could write a version of AutoEquatable merely by
> adding a couple items from the generics manifesto:
>
> protocol AutoEquatable: Equatable {}
>
> func == <T: AutoEquatable> (lhs: T, rhs: T) -> Bool {
> let lhsMirror = Mirror(reflecting: lhs)
> let rhsMirror = Mirror(reflecting: rhs)
>
> for ((lhsLabel, lhsValue), (rhsLabel, rhsValue)) in zip(lhs.children,
> rhs.children) {
> guard lhsLabel == rhsLabel else { return false }
>
> guard let lhsValue = (lhsValue as! Equatable) openas U else {
> return false }
> guard let rhsValue = rhsValue as? U else { return false }
> guard lhsValue == rhsValue else { return false }
> }
>
> return true
> }
>
> This is not the all-powerful code-generation-based solution everyone's pining
> for, of course. But (modulo a few bugs stemming from this being a proof of
> concept) it *would* work. If the compiler occasionally decides to write a
> more specialized equivalent, well, that's its prerogative, right?
>
> (In a recent thread on property reflection, I discussed the possibility of
> attaching lists of properties to types, with property behaviors being used to
> add properties to the lists. That would actually work better than `Mirror`
> for this task, but it's a more speculative feature.)
>
> As for an eventual compile-time-generated implementation, well, that kind of
> thing *does* seem to be on the design team's radar. We've already seen a
> concrete proposal along those lines in property behaviors; I could imagine a
> "type behaviors" feature being introduced in the future which could
> introspect a type and generate new members based on what it sees. And
> generalized hygienic macros keep coming up too. Just because they aren't in
> Swift 3 doesn't mean we can't design as though they'll be here eventually.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
