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

[Matthew Johnson]

Sent from my iPad

> On May 9, 2016, at 3:01 AM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>>> On May 7, 2016, at 11:51 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>> 
>>> 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.  
> 
> I just had a chance to digest Dave's answer. It explains a lot.
> 
> PureValue was defined in terms of the type's physical representation:
> - A struct with no reference properties
> - Recursively, a reference to immutable or uniquely referenced memory.
> 
> It's defined such that we can say Array<T> is a PureValue iff T is a PureValue.
> 
> There is currently no procedure for determining PureValue because we have no way to declare that references are immutable or uniquely referenced. It would be a promise by the developer.

Yes.  The same can be said of some semantic requirements in existing protocols, such as complexity requirements.  It is fair to observe that there is a difference here - not meeting complexity requirement slows things down, but doesn't fundamentally break.  Another example is the requirement to always return nil after you reach the end of IteratorType.

If it is possible to eventually have a mechanism that can be verified by the compiler we should wait to introduce the concept until that is in place.  Verifying value semantics would be the first step in that direction.

> 
> Now attempting to look at it from Dave's direction, value semantics apply to the variable's type, not the object's physical representation:
> 
> let v2 = v1
> f(v1)
> assert(v1 == v2)
> 
> If everything is a value, then this always works. Great!
> 
> If the variable's type does not allow mutating shared state, then operations on the variable are operating on a value.
> 
> protocol ValueP {
>   func compute() -> Result // nonmutating
> }
> 
> func g(v1 : ValueP) {
>   let v2 = v1
>   v1.compute()
>   assert(v1 == v2)
> }
> 
> Nice. ‘compute' cannot change the value. Those value semantics do not tell me anything about shared state or function purity. For that, I need some additional constraint on 'compute'. Knowing that it does not mutate the 'self' value is insufficient.
> 
> One way of doing that, for example, is to declare that 'compute' transitively cannot access globals *and* ValueP must be a PureValue. Now I can safely write this:
> 
> protocol ValueP : PureValue {
>   @strawman_noglobal func compute() -> Result
> }
> 
> /// Return (v1.compute, v2.compute)
> func g(v1 : ValueP, v2 : ValueP) -> (Result, Result) {
>   let r1 = v1.compute()
>   if v1 == v2 {
>     return (r1, r1)
>   }
>   return (r1, v2.compute())
> }
> 
> So, Dave is right that we need to decide soon whether we can make stronger assumptions about value semantics. But that is a separate question from how to express function purity.

Agree.  Nailing down value semantics is a big step in the right direction.

> I don't think there is any urgency in introducing things like the PureValue protocol or @strawman_noglobals attribute, now that we have clearly established shared-state-mutability-by-default. When we want to seriously have that discussion, we should consider other alternatives.

No argument from me.  I didn't mean to give a sense of urgency on this and am not attached to a specific mechanism.  I am advocating for the importance of eventually having a way to distinguish pure values from impure values (even if the have value semantics such as Array<UIView>).  If we don't get there in Swift 3 and the solution looks different than a PureValue protocol that is ok with me.

> I would prefer to wait until indirect structs and improved CoW support have had more discussion.

I've been thinking a lot about Dave's desire to "mandate" that value semantic types must be value types and allowing us to use reference identity for equality of reference types.  I would support that if these features were in place so I think shifting to those topics is a good next step for this discussion.  

Along those lines, I've been thinking about a proposal to allow the indirect modifier on any property that has a value type.  It may also be useful to allow the indirect modifier directly on struct and enum to allow type authors to indicate that all instances should be indirect.  Do you think it would it be worthwhile to pursue this proposal now?

Can you elaborate on what you have in mind with regards to improved CoW support?  Is there any chance of doing something here in Swift 3?
 
-Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160509/aa866f11/attachment.html>