3 ms·

I'm shocked by that they took the class/struct differentiation from swift. I HATED it when I had to deal with it in the past when working with swift. What's wro

by ii41 2y ago

I'm shocked by that they took the class/struct differentiation from swift. I HATED it when I had to deal with it in the past when working with swift. What's wrong with letting the programmer take the reference whenever they want to? Why do I have to change the whole class when I find something that makes me think it's better to have it passed by value? Why do I have to deal with the complexity of 2 kinds of custom types, with all the existing delicacies of a modern type system? Why on the earth would someone think this is a good idea that is worth taking? Can someone educate me on this?

delifue 2y ago
Not allowing take reference can avoid interior pointer. Interior pointers make memory safety harder and also make GC harder.
pjmlp 2y ago
The class/struct differentiation predates Swift by a few decades, it has come up in many other languages. Contrary to Go folks, Swift designers have done their work why some approaches are better than others based on historical use of language features.
quux 2y ago
My feeling is that if Swift didn't have the requirement of very tight interop with Objective-C there would have only been one kind of object. Maybe just structs with the option of heap allocation/reference counting or something like that. But that's not the world Swift was born into and so it has both classes that are optionally Obj-C compatible and structs
chubot 2y ago
As mentioned in another reply, being able to take the address of any value implies supporting interior pointers (pointers into the middle of a value) This is hard to implement in a memory-safe language. For example, the new WASM GC virtual machine does not support interior pointers. I noticed this distinction recently, regarding the rewrite of TypeScript in Go: https://lobste.rs/s/3q0ei5/10x_faster_typescript#c_xndrsg https://lobste.rs/s/3q0ei5/10x_faster_typescript#c_xndrsg - C#, Swift, Julia, Nim, Crystal, and very recently OCaml have separate value types and reference types. The choice is not orthogonal, which is what you don't like. (Java, Python, etc. do not have value types at all) - Only Go and D have the memory model of C (values and references), with GC. - Rust has also has the model of C, but with "static memory management"

by ii41 2y ago

delifue 2y ago

Not allowing take reference can avoid interior pointer. Interior pointers make memory safety harder and also make GC harder.

pjmlp 2y ago

The class/struct differentiation predates Swift by a few decades, it has come up in many other languages. Contrary to Go folks, Swift designers have done their work why some approaches are better than others based on historical use of language features.

quux 2y ago

My feeling is that if Swift didn't have the requirement of very tight interop with Objective-C there would have only been one kind of object. Maybe just structs with the option of heap allocation/reference counting or something like that. But that's not the world Swift was born into and so it has both classes that are optionally Obj-C compatible and structs

chubot 2y ago

As mentioned in another reply, being able to take the address of any value implies supporting interior pointers (pointers into the middle of a value) This is hard to implement in a memory-safe language. For example, the new WASM GC virtual machine does not support interior pointers. I noticed this distinction recently, regarding the rewrite of TypeScript in Go: https://lobste.rs/s/3q0ei5/10x_faster_typescript#c_xndrsg https://lobste.rs/s/3q0ei5/10x_faster_typescript#c_xndrsg - C#, Swift, Julia, Nim, Crystal, and very recently OCaml have separate value types and reference types. The choice is not orthogonal, which is what you don't like. (Java, Python, etc. do not have value types at all) - Only Go and D have the memory model of C (values and references), with GC. - Rust has also has the model of C, but with "static memory management"