>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
