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.
Sent from my iPhone > On May 4, 2016, at 13:32, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On May 4, 2016, at 11:12, Joe Groff via swift-evolution >>> <swift-evolution@swift.org> 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 >> 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
