[swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson]

Sent from my iPad

> On May 7, 2016, at 2:21 AM, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution <swift-evolution at 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.

Thank you for this clear exposition of how PureValue relates to pure functions.  This is the exact intuition I have about it but you have stated it much more clearly.

Language features to help automate CoW would be great.  It would eliminate boilerplate, but more importantly it would likely provide more information to the compiler.

> 
> 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
> }
> 
> 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.

I think the ability to define the value's boundary would be wonderful.  If we added a way to do this it would be a requirement of PureValue.

> 
> Anyway, these are only optimizer concerns, and programming model should take precedence in these discussion. But I thought that might help.
> 
> -Andy
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160507/3799b66f/attachment.html>