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

[Matthew Johnson]

> On May 15, 2016, at 1:48 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Mon May 09 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/>> wrote:
> 
>>> On May 8, 2016, at 1:51 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>>> 
>>> 
>>> on Sat May 07 2016, Andrew Trick <atrick-AT-apple.com> wrote:
>>> 
>> 
>>>>   On May 7, 2016, at 2:04 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>>> 
>>>>       2. Value types are not "pure" values if any part of the aggregate
>>>>       contains a
>>>>       reference whose type does not have value semantics. 
>>>> 
>>>>   Then Array<Int> is not a “pure” value (the buffer contained in an
>>>>   Array<Int> is a mutable reference type that on its own, definitely does
>>>>   *not* have value semantics). I don't think this is what you intend, and
>>>>   it indicates that you need to keep working on your definition.
>>>> 
>>>> It sounds like you’re changing the definition of value semantics to make it
>>>> impossible to define PureValue. 
>>> 
>>> Not on purpose.
>>> 
>>>> Does Array<T> have value semantics then only if T also has value
>>>> semantics?
>>> 
>>> This is a great question; I had to rewrite my response four times.
>>> 
>>> In my world, an Array<T> always has value semantics if you respect the
>>> boundaries of element values as defined by ==.  That means that if T is
>>> a mutable reference type, you're not looking through references, because
>>> == is equivalent to ===.
>>> 
>>> Therefore, for almost any interesting SomeConstraint that doesn't refine
>>> ValueSemantics, then
>>> 
>>> Array<T: SomeConstraint>
>>> 
>>> only has value semantics if T has value semantics, since SomeConstraint
>>> presumably uses aspects of T other than reference identity.  
>>> 
>>>> The claim has been made that Array always has value semantics,
>>>> implying that the array value’s boundary ends at the boundary of it’s
>>>> element values.
>>> 
>>> Yes, an array value ends at the boundary of its elements' values.
>>> 
>>>> That fact is what allows the compiler to ignore mutation of the
>>>> buffer.
>>> 
>>> I don't know what you mean here.
>>> 
>>>> It's perfectly clear that Array<T> is a PureValue iff T is a PureValue.
>>>> PureValue is nothing more than transitive value semantics.
>>> 
>>> You're almost there.  “Transitive” implies that you are going to look at
>>> the parts of a type to see if they are also PureValue's.  So which parts
>>> of the Array struct does one look at, and why?  Just tell me the
>>> procedure for determining whether a type is a PureValue.
>> 
>> We look at the observable parts.  
> 
> That begs the question.  The “parts” of an Array are the observable
> features that are considered by equality.
> 
>> We do not look at unobservable parts because we want flexibility to
>> use things like CoW, shared immutable references, etc in our
>> implementation.
> 
> IMO the important thing when it comes to functional purity is not what
> you *can* observe, but what you *do* observe.
> 
>> Can you share your definition of value semantics?  
> Explaining it well and in sufficient detail for this discussion takes
> some doing

I asked for your definition of value semantics because you keep asking for a concise definition of PureValue.  I was trying to identify how to structure a definition in a way that would be acceptable to you.   

> , but I think John Lakos and I share an understanding of value
> semantics and he has a really detailed explanation in
> https://www.youtube.com/watch?v=W3xI1HJUy7Q <https://www.youtube.com/watch?v=W3xI1HJUy7Q> and
> https://www.youtube.com/watch?v=0EvSxHxFknM <https://www.youtube.com/watch?v=0EvSxHxFknM>.  He uses C++ in places,
> but it's not particularly advanced, and the fundamental ideas apply just
> as well to Swift.

Thanks, good talks.  I believe I have seen earlier versions of them previously.

I’m still unsure of what structure would be acceptable to you as John doesn’t give a concise “here it is on one slide” definition of the kind you seem to be looking for with regards to pure value.  If anything, the talks demonstrate how nuanced this discussion is.

That said, I’ll take a shot at defining pure value using John’s terminology.  John talks about salient attributes quite a bit.  These are the “observable parts” I have been talking about.  

John also makes a very strong and clear distinction between “value semantics” and “in-core value semantics”.  This distinction is fundamental to the distinction I am making.  Your definition of “value semantics” appears to include both what John calls “value semantics” as well as what John calls “in-core value semantics”.  As far as I can tell my definition of “pure value” aligns with what John simply calls “value semantics” (or in some cases he says “full value semantics”) which *excludes* what he calls “in-core value semantics” (including pointers).  Quoting John:

“What kind of objects do not try to represent a value?  … Pointers actually represent something in the middle.  They don’t represent an ethereal type because pointers are addresses in a local machine.  That’s not a global property.  On the other hand they bear some resemblance so we call them in-core value types but they are not the same."

John uses “ethereal” interchangeably with platonic in his talk.  In his mind value semantic types are implementations that approximate platonic (or mathematical) values.  In other words, the interpretation / meaning of the value is eternal and is not tied to the current state of memory in the process that is executing.

The fundamental distinction between value semantics and pure value hinges on what salient attributes are allowable.   Pure values cannot have any salient attributes with what John is calling “in-core value semantics”.  All of the salient attributes of a pure value have what John is simply calling "value semantics”, or in other words are themselves pure values.

John doesn’t specifically discuss the semantics of something like vector<shared_ptr<T>> but I believe he would agree that it has different semantics than vector<int> in a fundamental and important way.

-Matthew


> 
>> It may be helpful
>> if we start there and refine your definition to exclude impure value
>> types like Array<UIView>.
>> 
>> In the meantime I’ll take another shot:
>> 
>> 1. Scalars are pure values.
>> 
>> 2. Any aggregate type with value semantics is a pure value iff all
>>   observable parts of the aggregate are pure values.
> 
> 
> -- 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/35d0cf72/attachment.html>