Jeremy,
The problem you present is not a mutability problem but rather a cache
design problem. If your hash value truly is expensive then you only want to
calculated it when you need to...
struct Person: Hashable
{
var firstName: String {didSet { _hashValue = nil }}
var lastName: String {didSet { _hashValue = nil }}
private var _hashValue: Int?
var hashValue: Int {
if _hashValue == nil {
_hashValue = firstName ^ lastName // the "expensive hash
calculation"
}
return _hashValue!
}
}
In the above implementation the hash value would only calculate the hash
when firstName or lastName were changed.
However in your example your hash method would calculate a new one every
time you copy a Person, but mine would not.
On Tue, Dec 20, 2016 at 6:44 AM Martin Waitz via swift-evolution <
[email protected]> wrote:
Am 2016-12-19 20:44, schrieb Erica Sadun via swift-evolution:
> https://github.com/apple/swift-evolution/pull/346
-1
I don't like where this is heading.
If you want to introduce method cascading, then have a look at Dart.
E.g. the example from the pull request could be something like this:
let questionLabel = UILabel()
..textAlignment = .Center
..font = UIFont(name: "DnealianManuscript", size: 72)
..text = questionText
The expression could still work on a mutable struct/class which later
becomes
immutable by using the `let` assignment.
The other example which silently creates a new instance is even worse.
If you want to do something like this, then please do it more
explicitly.
E.g.:
let fewerFoos = foos.clone()
..remove(at: i)
Anyway, all of this is simply syntactic sugar and should wait...
--
Martin
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
