Saw `class` in examples and want to clarify.. Are we discussing
auto-deriving for *value types only*. Or for classes also?
As I understand, there could be some additional questions/issues for this
feature because of class inheritance. But probably this feature could be
discussed for `final` classes also?
On 27.05.2016 22:41, plx via swift-evolution wrote:
On May 27, 2016, at 10:48 AM, Matthew Johnson <matt...@anandabits.com
<mailto:matt...@anandabits.com>> wrote:
On May 27, 2016, at 10:37 AM, plx via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
A `deriving` keyword, at the very least, is pretty explicitly *not* an
all-or-nothing situation. If you want to define equality/hashability
for your type manually, don't use `deriving`. This should leave the
simplest cases to auto generation and anything more complex should be
handled by the developer.
It’s all-or-nothing in the sense you can’t use a naive `deriving`
implementation to assist in any case where what you need is *almost* the
trivial implementation, but not quite.
Consider a case like this:
class QuxEvaluator {
let foo: Foo // Equatable
let bar: Bar // Equatable
let baz: Baz // Equatable
private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
// pure function of `foo`, `bar`, `baz`, and `identifier`
// expensive, and uses `quxCache` for memoization
func qux(for identifier: QuxIdentifier) -> Qux
}
…if it weren’t for `quxCache` we could easily synthesize `==` for
`QuxEvaluator`, but the trivial synthesis will yield invalid results due
to `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also
be equatable once conditional conformances are in place).
So we’re back to e.g. writing this:
extension QuxEvaluator : Equatable {
}
func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
lhs.baz == rhs.baz)
}
…just to omit a single field from the `==` consideration; this is
another sense in which you can say deriving is an all-or-none; there’s
just no way to invoke the synthesis mechanism other than for "all fields”.
I don’t see why this must necessarily be the case. Annotations such as
you describe below could be taken into account by `deriving`. `deriving`
is just a way to invoke the synthesis mechanism.
Different people are using it differently I think; I agree with you if it’s
just the name of the invocation, but I think at least some people are using
it as a shorthand for the “naive” implementation (all fields equatable =>
equatable).
That is, I meant "naive deriving” to refer to something like this (quoting
Patrick):
It would fail if not all members were Equatable or Hashable. If it was
automatic, you wouldn’t get any warning or sign at all. If you have to
explicitly conform to the protocols, then your intention is clear, and if
an automatic implementation cannot be made (because not all members were
Equatable or Hashable), then you will get an error that you need to
implement the protocol yourself like you do now (i.e. implement == and
hashValue).
…but I could’ve been clearer!
On the one hand, it’s possible to imagine a finer-grained form of this
synthesis that’d allow you to e.g. indicate a certain field should be
omitted (and also perhaps specialize how fields are compared, customize
the synthesized comparison ordering to put cheaper comparisons earlier,
and an endless list of other possible requests…).
If you don’t trust the compiler to optimize this well and therefore want
control over order of comparisons you should probably just implement it
manually. As you note below, this is a convenience feature that needs to
strike a fine balance.
I agree, but at the same time i think that scenarios like this:
struct RevisionInfo {
let contentID: NSUUID
let revisionID: NSUUID
let contentData: NSData
}
…aren’t going to be all that uncommon in practice; I think a good “layered”
implementation of the derivation/synthesis logic would suffice (e.g. we
wouldn't *need* special-case handling for ordering, potentially…).
IMO there are two issues involved:
1. How do we invoke the automatic synthesis.
2. How do we have some degree of control over the synthesis that happens.
`deriving` addresses issue 1 and says nothing about issue 2.
Agreed here; 2 is the interesting question. If you look at my initial
response in this thread I tried to suggest a “layered” approach:
Layer A: have some way of directly invoking the synthesis mechanism itself
(e.g. as a special-purpose macro-like construct); it should be powerful
enough to make `==` easy to write, but have some flexibility (implemented
or planned-for-future).
Layer B: add a way to synthesize `==` (etc.) via the construct from Layer A.
That’s my 2c on this topic; given it’s a Swift 4 topic at the very earliest
there’s a lot of time to figure it out.
_______________________________________________
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
