> On Aug 19, 2017, at 7:41 AM, Matthew Johnson <[email protected]> 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 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
}
}
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.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
