News for hackers. Stuff that matters.

A comment on Swift 6. Parent comment

Re:Swift 6 by kaba0 on Wednesday September 18, 2024 @12:01PM (#41581564)
If 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?

[ Parent | on HN ]
Re:Swift 6 by fauigerzigerk on Wednesday September 18, 2024 @02:00PM (#41583311)
In 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.

[ Parent | on HN ]