> On May 8, 2016, at 12:51 AM, Dave Abrahams <[email protected]> wrote: > > > on Sat May 07 2016, Matthew Johnson <matthew-AT-anandabits.com > <http://matthew-at-anandabits.com/>> wrote: > >>> On May 7, 2016, at 3:03 PM, Dave Abrahams <[email protected]> wrote: >>> >>> >>> on Sat May 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote: >>> >>>> This depends on the type. For types representing resources, etc it works >>>> just >>>> fine. But for models it does not work unless the model subgraph is entirely >>>> immutable and instances are unique. >>>> I agree that it isn't a good idea to provide a default that will >>>> certainly be wrong in many cases. >>> >>> Please show an example of a mutable model where such an equality would >>> be wrong. >> >> This is somewhat orthogonal to the main points I have been making in >> this thread. I have been focused on discussion about reference types >> that have value semantics and the distinction between value semantics >> and pure values. In any case, here you go: >> >> let a: NSMutableArray = [1, 2, 3] >> let other: NSMutableArray = [1, 2, 3] >> let same = a === other // false >> let equal = a == other // true > > That's not proof that an == for NSMutableArray that matches the behavior > of === would be wrong, just that it would be different from what we > currently have. > >> Reference equality does not match the behavior of many existing >> mutable model types. You seem to be making a case that in Swift it >> should. > > Yes. > >> But that is a separate discussion from the one I am trying to engage >> in because mutable reference types *do not* have value semantics. > > Then maybe I should disengage here? > >>>> Okay then, what algorithms can you write that operate on PureValue >>>> that >>>> don't work equally well on Array<AnyObject>? >>> >>> You haven't answered this question. How would you use this protocol? >> >> I answered elsewhere but I’ll repeat that one use that immediately >> comes to mind is to constrain values received in the initializer of a >> (view) controller to ensure that the observable state will not change >> over time. > > My claim is that substituting the constraint of “it has value > semantics,” while presumably looser than the PureValue constraint, would > not compromise the correctness of your view controller, so not only is > the meaning of PureValue hard to define, but it doesn't buy you > anything. If you want to refute that, just show me the code. > >> This is not an algorithmic use but is still perfectly valid IMO. > > If the properties of PureValue matter to your view controller, there's > an algorithm somewhere that depends on those properties for its > correctness.
In many cases it may just be view configuration that depends on those properties. I suppose you can call view configuration code an algorithm but I think that would fall outside of common usage. > >> If I read Andrew’s post correctly it sounds like it may also be of use >> to the optimizer in some cases. > > FWIW, I'm only interested in how you use this protocol in the > programming model, and I'm not even sure Andrew is talking about the > same constraint that you are. I am also primarily interested in the programming model. That said, as far as I can tell everything Andrew has said is talking about the exact same thing I am. Andrew, if I have said anything that doesn’t align with the constraint you’re talking about please let me know! > > > -- > -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
