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

[Dave Abrahams]

on Sun May 22 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

> Are you sure that is Sean’s entire point? I take more away from it than that.
> Look at slide 13 here:
> https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf
>
> “The shared structure also breaks our ability to reason locally about code”. 
>
> But I know you agree with that as well as you indicated just up thread. 
>
> It sounds like the only remaining point of possible disagreement is whether
> “can’t reach shared mutable state” is a reasonable constraint to place on types
> in generic code.

Here's what Sean sent me this morning:

> Hi Dave,
> 
> I've now had several people send me this transcript. I'm not seeing
> 
> Although I'm sure you know this - the short definition of regular is:
> 
>   copies are equal and logically disjoint.
> 
> Logically disjoint means that modifications to one copy do not modify
> other copies. It does not mean "no sharing" - sharing of an immutable
> part, a copy-on-write part (immutable when shared) or a part which is
> outside the definition of equality (such as a cache) are all
> allowed. We can write out all the axioms for a regular type if that
> would help. I do not know what the axioms of a "pure value" are, or
> how they would differ from this definition. Typically in functional
> programming (where "pure" is used to refer to functions that have no
> side effects) a value is not mutable and so the notion of disjoint
> does not come into question and there is typically significant
> sharing.
> 
> For "pure value" to be a useful concept we need an instance of a
> model, an algorithm that relies on the additional requirements, and
> the axioms that define it. From the thread it seems as if the
> definition is something like "copies are equal and physically
> disjoint." I'm not sure if there is something else people are trying
> to say along the lines that all parts are included in equality. I do
> not see any compelling evidence in the description that there are
> useful algorithms that rely on such attributes. Note that concepts are
> about enabling additional algorithms, including for efficiency.
> 
> [ Feel free to quote this back to the list - I can be easily reached
> at sparent at adobe.com if people have questions instead of speculating
> about what I did, or did not, mean in my talks. ]
> 
> Sean

...and now, I really need to get back to work on *my* talk for WWDC.

Cheers,

-- 
Dave