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

[Dave Abrahams]

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