on Sat May 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>> >> You haven't answered this question. How would you use this protocol? > > I think the best example was given by Andy when discussing pure > functions. Maybe I want to write a generic function and ensure it is > pure. I can only do this if I know that any arguments received that > compare equal will always present the same observable state. And that it doesn't touch any globals. > For example, maybe I wish to memoize the result. > > I cannot write such a function for all T, and I also cannot write such > a function for all T that have value semantics if we adopt the > “references are values” view of the world. Oh, you absolutely can, because if the function applies to all T that have value semantics, it only has a few operations to work with: initialization, assignment, and equality. Assignment is the only mutating one of these. > I need an additional constraint that rejects things like > Array<UIView>. (T would obviously also be constrained by a protocol > that exposes the properties or methods my function requires to compute > its result) Did you just start referring to T as the element type of the array instead of the function's parameter type? I think you're unintentionally pulling a fast one, reasoning-wise. It might help to write down some actual code. > In general, it would be used where you need to ensure that the result > of any operation observing the state of any part of the aggregate > value will always return the same value at any point in the future. > If I observe a[0].foo now I know with certainty the result of > observing a[0].foo at any point in the future. Sure, but what you need then is a constraint on a's Element type that it has value semantics, not some kind of new PureValue concept to use as a constraint on the array itself. > This aspect of preservation of observed values across time is > essential to the distinction between Array<LayoutValue> (see below) > and Array<UIView>. It doesn’t matter when I observe the frames of the > elements of Array<LayoutValue>, I will always get the same rects back. > With Array<UIView> that is obviously not the case as the frame of the > view could be mutated by anyone with a reference to the views at any > time in between my observations of the frame values. > > struct LayoutValue { > frame: CGRect > } > >> >>> let t = MyClass() >>> foo.acceptWrapped(Wrap(t)) >>> t.mutate() >>> >>> In this example, foo had better not depend on the wrapped >>> instance >>> not >>> getting >>> mutated. >>> >>> foo has no way to get at the wrapped instance, so it can't >>> depend on >>> anything about it. >>> >>> Ok, but this is a toy example. What is the purpose of Wrap? Maybe >>> foo >>> passes the >>> wrapped instance back to code that *does* have visibility to the >>> instance. My >>> point was that shared mutable state is still possible here. >>> >>> And my point is that Wrap<T> encapsulates a T (almost—I should >>> have >>> let >>> it construct the T in its init rather than accepting a T >>> parameter) >>> and >>> the fact that it's *possible* to code something with the >>> structure >>> of >>> Wrap so that it has shared mutable state is irrelevant. >>> >>> The point I am trying to make is that the semantic properties of >>> Wrap<T> depend >>> on the semantic properties of T (whether or not non-local >>> mutation >>> may be >>> observed in this case). >>> >>> No they do not; Wrap<T> was specifically designed *not* to depend on >>> the >>> semantic properties of T. This was in answer to what you said: >>> >>> A struct wrapping a mutable reference type certainly doesn’t >>> “feel” value semantic to me and certainly doesn’t have the >>> guarantees usually associated with value semantics (won’t >>> mutate behind your back, thread safe, etc). >>> >>> I have been trying to get you to nail down what you mean by >>> PureValue, >>> and I was trying to illustrate that merely being “a struct wrapping a >>> mutable reference type” is not enough to disqualify anything from >>> being >>> in the category you're trying to describe. What are the properties of >>> types in that category, and what generic code would depend on those >>> properties? >> >> Again, the key questions are above, asked a different way. >> >> -- >> -Dave -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution