@danielpunkass Odd.
@nuoji Incidentally, this also means that a hypothetical second implementation of the language would need to do all the same optimizations…
@nuoji Seems like you have to hope that the compiler never regresses and also that you can figure out what it's doing in pathological cases.
@nuoji Yes, that is the part that worries me. The compiler will get better, but there will always be things it can’t figure out.
@nuoji I guess this is what happens when you move functionality from the libraries into the language.
@nuoji Agreed. Do you think this is fixable?
@nuoji ObjC only copies when you say, and even then sometimes it's a no-op. Swift copies all the time, implicitly—and, again, often a no-op.
@nuoji Tricky implementations of NSData and NSString to link to other immutable objects when you split/join instead of copying data.
@nuoji Right. BTW, my understanding is that this sort of thing was once a (lesser) issue in ObjC as well.
@nuoji But ObjC is *more* explicit because you send different messages to immutable vs. mutable arrays.
@nuoji Aren't "var" and "inout" just different ways of spelling "mutable"? That's explicit.
@nuoji Yes, agreed about the perf being more hidden. I thought you were talking about "explicit" when reading the code.
@nuoji Yeah, one thing I've noticed is that it seems to be harder to read other people's Swift code than other people's Objective-C.
@nuoji Why do you say "not explicit"? Because the "var" may be textually far away?
@nuoji Yep. To me, the questions are 1. How much does the perf difference usually matter, and 2. Is there an escape hatch when it bites you.