Sent from my iPad

> On Aug 19, 2017, at 9:33 PM, Brent Royal-Gordon <br...@architechies.com> 
> wrote:
> 
>> On Aug 19, 2017, at 7:41 AM, Matthew Johnson <matt...@anandabits.com> wrote:
>> 
>> Regardless of which approach we take, it feels like something that needs to 
>> be implicit for structs and enums where value semantics is trivially 
>> provable by way of transitivity. When that is not the case we could require 
>> an explicit `value` or `nonvalue` annotation (specific keywords subject to 
>> bikeshedding of course).
> 
> There is no such thing as "trivially provable by way of transitivity". This 
> type is comprised of only value types, and yet it has reference semantics:
> 
>       struct EntryRef {
>               private var index: Int
>               
>               var entry: Entry {
>                       get { return entries[index] }
>                       set { entries[index] = newValue }
>               }
>       }

This type uses global mutable state in its implementation.  This is not hard 
for the compiler to detect and is pretty rare in most code.

> 
> This type is comprised of only reference types, and yet it has value 
> semantics:
> 
>       struct OpaqueToken: Equatable {
>               class Token {}
>               private let token: Token
>               
>               static func == (lhs: OpaqueToken, rhs: OpaqueToken) -> Bool {
>                       return lhs.token === rhs.token
>               }
>       }

Yes, of course this is possible.  I believe this type should have to include an 
annotation declaring value semantics and should also need to annotate the 
`token` property with an acknowledgement that value semantics is being 
preserved by the implementation of the type despite this member not having 
value semantics.  The annotation on the property is to prevent bugs that might 
occur because the programmer didn't realize this type does not have value 
semantics.

> 
> I think it's better to have types explicitly declare that they have value 
> semantics if they want to make that promise, and otherwise not have the 
> compiler make any assumptions either way. Safety features should not be 
> *guessing* that your code is safe. If you can somehow *prove* it safe, go 
> ahead—but I don't see how that can work without a lot of manual annotations 
> on bridged code.

I agree with you that *public* types should have to declare that they have 
value semantics.  And I'm not suggesting we attempt to *prove* value semantics 
everywhere. 

I'm suggesting that the proportion of value types in most applications for 
which we can reasonably infer value semantics is pretty large.  If the stored 
properties of a value type all have value semantics and the implementation of 
the type does not use global mutable state it has value semantics.  

Whether we require annotation or not, value semantics will be decided by the 
declaring module.  If we don't infer it we'll end up having to write `value 
struct` and `value enum` a lot.  The design of Swift has been vigorous in 
avoiding keyword soup and I really believe that rule applies here.  The primary 
argument I can think of against inferring value semantics for non-public value 
types in these cases is if proving a type does not use global mutable state in 
its implementation would have too large an impact on build times.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to