[swift-evolution] "with" operator a la O'Caml?

[Jeremy Pereira]

> On 20 Dec 2016, at 13:10, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Dec 20, 2016, at 4:32 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 20 Dec 2016, at 07:54, Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> But for a struct to be immutable, you don't need all its properties to be let. (I guess that's Derrick's point)
>> 
>> Yes you do. Consider
>> 
>> struct Person: Hashable
>> {
>>   let firstName: String
>>   let lastName: String
>>   let hashValue: Int
>> 
>>   init(firstName: String, lastName: String)
>>   {
>>       self.firstName = firstName
>>       self.lastName = lastName
>>       self.hashValue = firstName.hashValue ^ lastName.hashValue
>>   }
>> }
>> 
>> func == (l: Person, r: Person) -> Bool
>> {
>>   return l.firstName == r.firstName && l.lastName == r.lastName
>> }
>> 
>> Pretend that the hash value is quite expensive to calculate so I only want to do it once. With the above code, this is fine but if I change the lets to vars (e.g. var firstName: String), I am open to
>> 
>> let chris = Person(firstName: “Chris”, lastName: “Lattner”) // Immutable
>> 
>> var andy = chris
>> andy.firstName = “Andy”
>> 
>> andy.hashValue // Gives the wrong answer unless you are exceptionally lucky.
>> 
>> I’ve used hashValue, but the same argument would apply to any computed property where you might want to cache the computed value. As soon as you make any of the properties that the computed property depends on `var`, you have to add code that invalidates the cached value which is a performance and a complexity hit for your struct.
> 
> The performance hit is likely a bit larger if you *don't* use a mutable property and instead create a whole new instance.

How is 

    let a = SomeStruct()
    var b = a

not creating a new instance?

Anyway, the cost depends on how expensive the calculation for the calculated property is and how often you use it and how well the compiler can optimise copies of immutable objects.

On the other hand, making a property that is not supposed to change over the lifetime of the object a let property is self documenting and not to be avoided IMO.

> 
> It might be interesting to think about language solutions to reduce this complexity.   But in general, the mutability model of Swift's value types is an asset and should be embraced, not avoided.  That's what a "Swifty" solution would do IMO.

Yeah, I really hate it when people say “x is Swifty” or “y is not Swifty”. What is Swifty or not usually depends on what the person saying it prefers. On the other hand, most programmers i have come across agree that writing code that is self documenting is good practice and therefore using let instead of var for properties that never change over the life time of the object counts in that respect in my opinion.


>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution