3 ms·
The thing is, each string-related answer ended up extending it with some methods that everyone wanted it to have in the first place, and the top-voted comments
by paperplatter 2y ago
The thing is, each string-related answer ended up extending it with some methods that everyone wanted it to have in the first place, and the top-voted comments are like "why do we have to do this." It also shouldn't have required multiple updates to each answer.
The time I was doing a lot of string manipulation in a team Swift project, we had to write our own wrapper that basically stored strings as arrays of printable characters because the native one was too annoying. This also protected us from all the breaking changes Apple made to strings across Swift versions.
The inout one is different. It's confusing that arrays and dicts are structs, which have different rules from regular objects, and the syntax takes some getting used to:
func addItem(_ localArr: inout [Int]) {
localArr.append(4)
}
- stephencanon 2y ago> It's confusing that arrays and dicts are structs, which have different rules from regular objects As a long-time assembly and C programmer and now Swift programmer, I would say that structs _are_ regular objects, and things with reference semantics are weird. It all depends on your point of view!
- paperplatter 2y agoI'm fine with either approach as long as it's consistent. Practical Swift code will have a few "inout"s sprinkled around, wherever someone happened to pass in a struct (like array) instead of an object (like NSArray). And that's without bridging and stuff like UnsafePointer involved. Edit: Just remembered that arrays still don't act like regular structs either! https://stackoverflow.com/questions/24450284/conflicting-definition-of-swift-struct-and-array/24454610#24454610 https://stackoverflow.com/questions/24450284/conflicting-def...
- fauigerzigerk 2y agoI'm fine with either approach if it's easy to know which one I'm using at a any particular call site. C# started the tradition of moving this information to the type level, far away from the call site. Swift has adopted this terrible idea. The philosophy of making code look "clean" at the cost of hiding critical information in some far away place is the biggest mistake in programming language design. If code happens to look clean it should be the result of being simple rather than being cleansed for effect. Other bad ideas in the same vein are computed properties and function builders.
- neonsunset 2y agoWhat do you mean by moving information to the type level?
- fauigerzigerk 2y agoIn C and C++ (and many other languages) the distinction between value and reference/pointer is part of the variable declaration. In C# and Swift that information belongs to type definitions (except for inout parameters). Structs are value types and classes are reference types. Type definitions are usually further away from the call site than variable declarations. Also, in C, accessing a member of a struct through a pointer requires the -> operator providing yet another clue as to whether you're using a pointer or a value. In my opinion, this distinction is absolutely key. It should always be obvious at the call site. I don't think there is anything that has caused more bugs in my Swift code than getting this wrong. Change a type from class to struct or vice versa and chances are your code still compiles when it really shouldn't because it's now completely broken.
- kaba0 2y agoIf there are identity having classes (reference/pointer) that may be mutable, and value types that are always immutable, then I think it can be an “implementation detail”, part of the type, not changing semantics. If you can’t change a struct’s field, only the whole struct, then I believe it’s fine - and the compiler may decide to copy it or change in-place depending on its available context, is it not the case?
- fauigerzigerk 2y agoIn a language without mutability (or perhaps with something like borrow checking?), it would not be a problem. But in Swift, the option of introducing mutability always exists. It's not impossible to impose some sort of discipline to mitigate these issues, but why is it a good idea to make values and references indistinguishable at the call site? I don't get it. But it's not surprising. I don't get a lot of decisions that language designers have been making. The entire drive towards more and more syntactical abstraction in order to make everything look like a DSL is a mistake in my opinion.
- stephencanon 2y agoThe answer you link to there is from the Swift 1 days in 2014. It was absolutely true then, but array has had true value semantics since shortly after that answer was written.
- paperplatter 2y agoAh, it's coming back to me now. I remember when they fixed that and I was relieved.