Sent from my iPad
On May 25, 2016, at 8:08 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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. > > In other words, Keep It Simple, Stupid. > <https://en.wikipedia.org/wiki/KISS_principle> > > -- > 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
