on Sat May 07 2016, Andrew Trick <atrick-AT-apple.com> wrote: > On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > I don’t mean to imply that it is the *only* valuable > property. However, it I (and many others) do believe it is an > extremely > valuable > property in many cases. Do you disagree? > > I think I do. What is valuable about such a protocol? What generic > algorithms could you write that work on models of PureValue but don't > work just as well on Array<Int>? > > class Storage { > var element: Int = 0 > } > > struct Value { > var storage: Storage > } > > func amIPure(v: Value) -> Int { > v.storage.element = 3 > return v.storage.element > } > > I (the optimizer) want to know if 'amIPure' is a pure function. The developer > needs to tell me where the boundaries of the value lie. Does 'storage' lie > inside the Value, or outside? If it is inside, then Value is a 'PureValue' and > 'amIPure' is a pure function. To enforce that, the developer will need to > implement CoW, or we need add some language features. > > If I know about every operation inside 'amIPure', and know where the value's > boundary is, then I don't really need to know that 'Value' is a 'PureValue'. > For > example, I know that this function is pure without caring about 'PureValue'. > > func IAmPure(v: Value, s: Storage) -> Int { > var t = v > t.storage = s > return t.storage.element > }
How do you know this? t.storage can be a computed property. I think you're assuming a lot of information is being communicated to me and to the compiler from the types in the signature (e.g. can Value be a reference type?) > However, I might only have summary information. I might know that the function > only writes to memory reachable from Value. In that case, it would be nice to > have summary information about the storage type. 'PureValue' is another way of > saying that it does not contain references to objects outside the value's > boundary (I would add that it cannot have a user-defined deinit). The only > thing > vague about that is that we don't have a general way for the developer to > define > the value's boundary. It certainly should be consistent with '==', but > implementing '==' doesn't tell the optimizer anything. > > Anyway, these are only optimizer concerns, and programming model should take > precedence in these discussion. Indeed, I am arguing from the point of view of the programming model. I am very wary of introducing protocols that are only there for the use of the optimizer. -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution