> On May 5, 2016, at 2:51 PM, Dave Abrahams <[email protected]> wrote: > > > on Thu May 05 2016, Matthew Johnson <matthew-AT-anandabits.com > <http://matthew-at-anandabits.com/>> wrote: > >> Sent from my iPad >> >>> On May 5, 2016, at 10:59 AM, Dave Abrahams <[email protected]> wrote: >>> >>> >>> on Wed May 04 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote: >>> >>>>> On May 4, 2016, at 4:16 PM, David Sweeris <[email protected]> wrote: >>>>> >>>>> Having given it some more thought... Does "PureReference" make >>>>> sense? What would it mean? At some point a reference has to, you >>>>> know, actually refer to a concrete value. Otherwise it's just >>>>> turtles all the way down. >>>> >>>> In my thinking PureReference (or ImmutableObject) has semantics >>>> indicating that the type is a value-semantic reference type. I think >>>> this could be quite useful in some cases. >>> >>> Like what? To a first approximation, the only thing I can see this being >>> useful for is Objective-C interop. Aside from being an element of an >>> NSArray, there's nothing a an immutable class can do that a struct >>> can't. >> >> Objective-C / cocoa interop is important enough to matter IMO. > > Sure. I don't see why we should have an ImmutableObject protocol when > we can just compose “Immutable” with “AnyObject.”
Yes, fair enough. A typealias is easy enough to add if it is used frequently. I wouldn’t call it “Immutable” though as “PureValue" indicates what we care about (value semantics). “ImmutableObject” is just a good name for a value semantic reference type as immutability is the only way to achieve value semantics with a reference type. It would be great to see “PureValue” added to the standard library and applied to its types. This would allow us to start drawing the distinction you make in your third category which is very important for many reasons, but is only latent today. > >> >> >>> >>>> >>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On May 4, 2016, at 13:32, Matthew Johnson <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On May 4, 2016, at 11:12, Joe Groff via swift-evolution >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> I can see value in there being some kind of PureValue protocol, >>>>>>>> for types that represent fully self-contained values, but >>>>>>>> conforming to that protocol requires a bit more thought than just >>>>>>>> being a struct or enum, since there are structs that have >>>>>>>> reference semantics (such as UnsafePointer), and there are hybrid >>>>>>>> value types that contain references to data that isn't part of >>>>>>>> the value (an Array<Class>, for instance). >>>>>>>> >>>>>>>> -Joe >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I'd think that both "PureValue" and "PureReference" would be >>>>>>> useful. Isn't it the mixed types that make for tricky mutation >>>>>>> rules & serialization? >>>>>> >>>>>> I also like Joe’s idea. It fits with the direction in Swift of >>>>>> attaching semantics, not just syntax, to protocols. >>>>>> >>>>>> I was thinking of something pretty similar to your PureReference >>>>>> idea, but slightly different. Pure / immutable references have >>>>>> value semantics. With that in mind I was thinking of an >>>>>> ImmutableObject protocol which would inherit from both AnyObject >>>>>> and PureValue. >>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> -- >>> Dave > > -- > Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
