Regards (From mobile)
> On May 26, 2016, at 3:46 AM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > > > Sent from my iPad > > On May 25, 2016, at 8:08 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >>> Omission of fields from generated computations >>> >>> Should it be possible to easily omit certain properties from automatically >>> generated equality tests or hash value computation? This could be valuable, >>> for example, if a property is merely used as an internal cache and does not >>> actually contribute to the "value" of the instance. Under the rules above, >>> if this cached value was equatable, a user would have to override == and >>> hashValue and provide their own implementations to ignore it. If there is >>> significant evidence that this pattern is common and useful, we could >>> consider adding a custom attribute, such as @transient, that would omit the >>> property from the generated computations. >> >> A word of warning: an earlier proposal on memberwise initializers ran >> aground because it tried to annotate properties to tell the compiler which >> ones should be included in the generated initializer. It was ultimately >> judged too complex a solution for the specialized problem space it was >> trying to tackle. > > That's not entirely true. The solution the core team was leaning towards in > their feedback also included property annotations. The proposal was deferred > because a lot of new ideas were discussed during the review period and our > understanding of the design space was refined. By the end of the review not > even I was convinced that the proposal as written was the right long term > solution. > > If we're going to derive automatic Equatable and Hashable implementations it > is necessary to exclude certain members. We can talk about strategies for > doing that, and possibly for minimizing cases where the annotations are used, > but we need some kind of control. > > The common case where annotations will be required is likely to be for a > small number of members relative to those contributing to Equatable and > Hashable. An annotation or two are much better than writing out manual > implementations. They also scale nicely if we are able to derive > implementations of other protocols in the future. > There are existing precedents that even show what the code looks like... and it is not bad at all. >> >> In other words, Keep It Simple, Stupid. >> <https://en.wikipedia.org/wiki/KISS_principle> >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
