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

[L Mihalkovic]

>>        The primary reasons I can think of for creating reference types with
>>        value
>>        semantics are avoiding copying everything all the time or using
>>        inheritance. (I
>>        could also list pre-existing types here but am not as concerned with
>>        those)
>> 
>>        One could argue that you can avoid copying by writing a struct with a
>>        handle and
>>        one can simulate inheritance by embedding and forwarding. The problem is
>>        that
>>        this involves a lot of boilerplate and makes your code more complex. 
>> 
>>    The “forwarding boilerplate problem” is something we need to solve in
>>    the language regardless. 
>> 
>> Yes I agree that it needs to be solved regardless. In fact, you might remember
>> that I invested quite a bit of effort into drafting a proposal on the topic. I
>> shelved it mostly because I became very busy with client work, but also partly
>> due to the lukewarm reaction.
>> 
>>    The fact that we don't have an answer today
>>    shouldn't prevent us from adopting the right model for values and
>>    references.
>> 
>> I think that depends on what you mean by this. If you mean providing a default
>> equality of reference identity for reference types I disagree. I think that
>> should wait until the language reaches a place where there is no good reason to
>> write value semantic reference types. And I believe the boilerplate currently
>> required to wrap them in a struct is sufficiently burdensome that this is not
>> the case yet.
> 
> As I've said, we can't wait.  We should make the change and use that to
> drive development of the necessary features to reduce the burden of
> writing optimized code.  
> 
> Remember that the only value semantic reference types are immutable, so
> the struct rendition of such types has only immutable properties.
> Personally, I don't think that transforming
> 
>        struct X {
>          ...
>        private:
>          let prop1: Type1
>          let prop2: Type2
>          let prop2: Type3
>        }
> 
> into
> 
>        struct X {
>           ...
>        private:
>          class Storage {
>            let prop1: Type1
>            let prop2: Type2
>            let prop2: Type3
>          }
>          let value: Storage
>        }
> 
> is so awful if you find you need to optimize away some reference
> counting manually; you just need to add “.value” to property accesses in
> X's methods, and this doesn't require any forwarding.
> 


FWIW +1. pandora’s box never fully seals back... so it is easier to force explicit extra syntax early and later decide that under some special conditions the requirements can be relaxed. Considering the timeline for 3.00 as well as its associated stake, the aforementioned syntax represents a coherent (if not yet fully minimizing of user’s efforts) programing model that could be lived with for the foreseeable future, all the while not closing the door on certain types of future simplification. 

For example the following syntax is a straw man representation of what could be done at a future date to reduce the boilerplate:

       struct X {
         ...
       private:
         @strawman_syntax1 let prop1: Type1
         let prop2: @strawman_syntax2 Type2
         strawman_syntax3 let prop2: Type3
       }

To extend on ‘value semantic reference type’, esthetic considerations would push me towards a solution expressing it at the usage site (like in the straw man syntax above), rather than via the introduction of a new protocol to be used at the definition site. i.e. favoring "my usage here of Type1 instances is to be construed as having value semantic” (with the compiler or me crafting a different definition of identity) over the less self documenting “Class Type1 is for all eternity carrying value semantic”, which ultimately seems more confusing to me. 
I call it an esthetic argument as it is based on nothing else than a personal view on symmetry: (for no good reason) I value symmetry as the sign of a *good* design. Struct and Class are structural constructs to express a specific notion in the language. Out of my desire for symmetry I would expect that anything altering my perception of this notion would have to be equally conveyed within the structure of the language. Resorting to protocol compliance to do the same strikes me as the kind of deep imbalance I try to avoid.

/LM

>> 
>>    So far, I still don't believe that introducing a “pure values”
>>    distinction is adding simplicity and clarity. To me it looks like
>>    a needless wrinkle.
>> 
>> Fair enough. I suspect that many folks who have been strongly influenced by
>> functional programming may have a different opinion (btw, I don’t mean to imply
>> anything about the degree to which functional programming has or has not
>> influenced your opinion).
> 
> -- 
> -Dave
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160508/24c53e5d/attachment.html>