8 ms·

Man I get vertigo reading this. Reminds me of trying to understand Java constructors and object initialisation. It’s been a while now, and at least in my exper

Man I get vertigo reading this. Reminds me of trying to understand Java constructors and object initialisation. It’s been a while now, and at least in my experience so far Go and Rusts choice of not having special constructors really simplifies a lot. Is there anyone that’s had the experience of missing constructors once you swapped away from them?

_ZeD_ 2y ago
dude, java constructor are easy... that C++ stuff is really black magic and from what I understand rust constructors are basically the same as java, no?
- masklinn 2y ago
  Rust does not have constructors at all[0], it uses factory functions (conventionally named `new_somethignsomething`) but those are not special to the language. [0] except in the more generalised haskell-ish sense that structs or enum variants can be constructed and some forms (“tuple structs” and “tuple variants”) will expose an actual function
  - collinvandyck76 2y ago
    I've often longed for first class constructors in Go and Rust. It was more of a problem for me with Go because you can omit a struct field when building a value, something you can't do in Rust unless it has an explicit Default impl and even then you have to explicitly add ..Default::defualt() when you're building the value. I never thought that constructors were that burdensome and therefore do not understand the omission in other languages like Go and Rust that followed. Quite the opposite really -- knowing that a type always went through a predefined init was comforting to me when writing Java.
    - gavindean90 2y ago
      I think people don’t like constructors because of the potential side effects of something happening in constructors, especially if the constructor is big or doesn’t finish properly.
- mmaniac 2y ago
  Rust doesn't have constructors. By convention, a static method called new returns a struct - no magic.
- jakewins 2y ago
  I think if you think constructors in Java are easy, you are much, much smarter than I am or have missed some really, really subtle footguns. Eg: - Java constructors can return the object before they complete construction, finishing at a later time; this is visible in concurrent code as partially constructed objects - Java constructors can throw exceptions and return the partially constructed object at the same time, giving you references to broken invalid objects - Just.. all the things about how calling super constructors and instance methods interleaved with field initialization works and the bazillion ordering rules around that - Finalizers in general and finalizers on partially constructed objects specifically I don't in any way claim it's on the same level as C++, but any time I see a Java constructor doing any method calls anymore - whether to instance methods or to super constructors - I know there are dragons
  - SpaghettiCthulu 2y ago
    > - Java constructors can return the object before they complete construction, finishing at a later time; this is visible in concurrent code as partially constructed objects > > - Java constructors can throw exceptions and return the partially constructed object at the same time, giving you references to broken invalid objects Java constructors do not actually return the object. In Java code, it would appear to the caller as though the contructor returns the new instance, but that is not really the case. Instead, the new object is allocated and then the constructor is called on the object in (almost) the same manner as an instance method. Additionally, Java constructors can only leak a partially initialized object if they store a `this` reference somewhere on the heap (for example, by spawning a thread with a reference to `this`). The assertion that this gives you a reference to a "broken invalid object" is only potentially correct from the perspective of invariants assumed by user-written code. It is perfectly valid and well-defined to the JVM. > - Just.. all the things about how calling super constructors and instance methods interleaved with field initialization works and the bazillion ordering rules around that This is a gross mischaracterization of the complexity. There is only a single rule that really matters, and that is "no references to `this` before a super constructor is called". Until very recently, there was also "no statements before a super constructor is called". > - Finalizers in general and finalizers on partially constructed objects specifically Finalizers are deprecated.
- DougBTX 2y ago
  Inside a constructor you can access a partially initialised "this" value, and even call methods on it, which leads to rules like: "Do not call overridable methods in constructors"[0], as they can lead to surprising, non-local, bugs. Rust has functions associated with types which are conventionally used like constructors, but critically the new objects must have all their fields provided all at once, so it is impossible to observe a partially initialised object. [0] https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2214 https://learn.microsoft.com/en-us/dotnet/fundamentals/code-a...
  - titzer 2y ago
    Virgil solved this a little differently. The initialization expressions for fields (outside of constructors) as well as implicit assignment of constructor parameters to fields happens before super constructor calls. Such initialization expressions cannot reference "this"--"this" is only available in _constructor bodies_. Initializing fields before calling super and then the chaining of super calls guarantees the whole chain of super constructor calls will finish before entering the body of a constructor, and all fields will be initialized. Thus by construction, virtual methods invoked on "this" won't see uninitialized fields. https://github.com/titzer/virgil/blob/master/doc/tutorial/Classes.md#initialization-order https://github.com/titzer/virgil/blob/master/doc/tutorial/Cl...
  - zozbot234 2y ago
    You can most likely use session types to soundly observe a partially initialized MaybeUninit<MyObject> in Rust. The proper use of session types could ensure that the object is only assumed to be initialized after every field of it has been written to, and that no uninitialized fields are ever accessed in an unsound way. The issue though is that this is not automated in any way, it requires you to write custom code for each case of partial initialization you might be dealing with.
masklinn 2y ago
There are a few somewhat esoteric cases where constructors working in-place allow magic which can be hard to replicate otherwise e.g. Rust is still missing guaranteed “placement new” type behaviour. Unless you want to `ptr::write` individual fields by hand into a `MaybeUninit`, which you can absolutely do mind but that… is not very ergonomic, and requires structs to be specifically opted into this.
- wongarsu 2y ago
  Which can be an issue if you want to initialize a 2MB large heap-allocated object (e.g. heap-allocating a large nested struct or a big array). Without guaranteed “placement new” that can mean that your 2MB object gets constructed on the stack and copied to the heap. And while Linux defaults to a 4MB stack, Windows defaults to 1MB and will crash your program. Or it might work if the compiler optimizes in your favor. It's not something you encounter frequently, it can be worked around, and Rust will eventually solve it ergonomically without introducing constructor hell (probably with just a keyword). But finding the best language-level solution isn't straightforward (efforts to fix this for rust are ongoing for 9 years)
  - bennettnate5 2y ago
    It can also be an issue if you want to wrap any API that requires fixed memory locations for objects (such as POSIX semaphores). It's UB to call a POSIX semaphore from any other memory location than where it was initialized, so making a `Semaphore::new()` API is just asking for trouble. You can deal with it by `Box`ing the semaphore, but then you can't construct the semaphore in a shared memory segment (one of the stronger use cases for process-shared semaphores). I have a hunch this is why there's no Semaphore implementation in the Rust standard library, though it could be due to fundamental inconsistencies in semaphore APIs across OSs as well ¯\_(ツ)_/¯
    - masklinn 2y ago
      No, Rust doesn't have semaphores in the stdlib[0] because it was not clear what precise semantics should be supported, or what purpose they would serve since by definition they can't mitigate exclusive and thus write access to a resource and mitigating access to code isn't much of a rust convention. And nobody has really championed their addition since. Furthermore, they still present a fair amount of design challenges in the specific context of Rust: https://neosmart.net/blog/implementing-truly-safe-semaphores-in-rust/ https://neosmart.net/blog/implementing-truly-safe-semaphores... [0] technically they were there, added in 0.4, never stabilised, deprecated in 1.7, and removed in 1.8
throwawaymaths 2y ago
I mean go's zero initialization requires a bit of language lawyering sometimes too. https://codefibershq.com/blog/golang-why-nil-is-not-always-nil https://codefibershq.com/blog/golang-why-nil-is-not-always-n...
chipdart 2y ago
> It’s been a while now, and at least in my experience so far Go and Rusts choice of not having special constructors really simplifies a lot. This take makes no sense. Think about it: you're saying that not having the compiler do any work for you "really simplifies things a lot". Cool, so you have to explicitly declare and define all constructors. That's ok. But think about it, doesn't C++ already offer you that option from the very start? I mean, you are talking about a feature in C++ that is not mandatory or required, and was added just to prevent those programmers who really really wanted to avoid writing boilerplate code to lean on the compiler in and only in very specific corner cases. If for any reason you want the compiler to do that work for you, you need to be mindful of the specific conditions where you can omit your own member functions. For the rest of the world, they can simply live a normal life and just add them. How is this complicated? Complaining that special member functions make obvious things less simple is like complaining that English is not simple jus because you can find complicated words in a dictionary. Yes, you can make it complicated if that's what you want, but there is nothing forcing you to overcomplicate things, is there?
- tyg13 2y ago
  You're mistaken. Rust does not require you to define all constructors. Rust does not have constructors. All structs in Rust must be initialized using brace syntax, e.g. `Foo { bar: 1, baz: "" }`. This is commonly encapsulated into static functions (e.g. `Foo::new(1, "")`) that act similarly to constructors, but which are not special in any way compared to other functions. This avoids a lot of the strangeness in C++ that arises from constructors being "special" (can't be named, don't have a return type, use initializer list syntax which is not used anywhere else). This combined with mandatory move semantics means you also don't have to worry about copy constructors or copy-assignment operators (you opt into copy semantics by deriving from Clone and explicitly calling `.clone()` to create a copy, or deriving from Copy for implicit copy-on-assign) or move constructors and move-assignment operators (all non-Copy assignments are moves by default). It's actually rather refreshing, and I find myself writing a lot of my C++ code in imitation of the Rust style.
  - chipdart 2y ago

_ZeD_ 2y ago

dude, java constructor are easy... that C++ stuff is really black magic and from what I understand rust constructors are basically the same as java, no?

masklinn 2y ago
Rust does not have constructors at all[0], it uses factory functions (conventionally named `new_somethignsomething`) but those are not special to the language. [0] except in the more generalised haskell-ish sense that structs or enum variants can be constructed and some forms (“tuple structs” and “tuple variants”) will expose an actual function
- collinvandyck76 2y ago
  I've often longed for first class constructors in Go and Rust. It was more of a problem for me with Go because you can omit a struct field when building a value, something you can't do in Rust unless it has an explicit Default impl and even then you have to explicitly add ..Default::defualt() when you're building the value. I never thought that constructors were that burdensome and therefore do not understand the omission in other languages like Go and Rust that followed. Quite the opposite really -- knowing that a type always went through a predefined init was comforting to me when writing Java.
  - gavindean90 2y ago
    I think people don’t like constructors because of the potential side effects of something happening in constructors, especially if the constructor is big or doesn’t finish properly.
mmaniac 2y ago
Rust doesn't have constructors. By convention, a static method called new returns a struct - no magic.
jakewins 2y ago
I think if you think constructors in Java are easy, you are much, much smarter than I am or have missed some really, really subtle footguns. Eg: - Java constructors can return the object before they complete construction, finishing at a later time; this is visible in concurrent code as partially constructed objects - Java constructors can throw exceptions and return the partially constructed object at the same time, giving you references to broken invalid objects - Just.. all the things about how calling super constructors and instance methods interleaved with field initialization works and the bazillion ordering rules around that - Finalizers in general and finalizers on partially constructed objects specifically I don't in any way claim it's on the same level as C++, but any time I see a Java constructor doing any method calls anymore - whether to instance methods or to super constructors - I know there are dragons
- SpaghettiCthulu 2y ago
  > - Java constructors can return the object before they complete construction, finishing at a later time; this is visible in concurrent code as partially constructed objects > > - Java constructors can throw exceptions and return the partially constructed object at the same time, giving you references to broken invalid objects Java constructors do not actually return the object. In Java code, it would appear to the caller as though the contructor returns the new instance, but that is not really the case. Instead, the new object is allocated and then the constructor is called on the object in (almost) the same manner as an instance method. Additionally, Java constructors can only leak a partially initialized object if they store a `this` reference somewhere on the heap (for example, by spawning a thread with a reference to `this`). The assertion that this gives you a reference to a "broken invalid object" is only potentially correct from the perspective of invariants assumed by user-written code. It is perfectly valid and well-defined to the JVM. > - Just.. all the things about how calling super constructors and instance methods interleaved with field initialization works and the bazillion ordering rules around that This is a gross mischaracterization of the complexity. There is only a single rule that really matters, and that is "no references to `this` before a super constructor is called". Until very recently, there was also "no statements before a super constructor is called". > - Finalizers in general and finalizers on partially constructed objects specifically Finalizers are deprecated.
DougBTX 2y ago
Inside a constructor you can access a partially initialised "this" value, and even call methods on it, which leads to rules like: "Do not call overridable methods in constructors"[0], as they can lead to surprising, non-local, bugs. Rust has functions associated with types which are conventionally used like constructors, but critically the new objects must have all their fields provided all at once, so it is impossible to observe a partially initialised object. [0] https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2214 https://learn.microsoft.com/en-us/dotnet/fundamentals/code-a...
- titzer 2y ago
  Virgil solved this a little differently. The initialization expressions for fields (outside of constructors) as well as implicit assignment of constructor parameters to fields happens before super constructor calls. Such initialization expressions cannot reference "this"--"this" is only available in _constructor bodies_. Initializing fields before calling super and then the chaining of super calls guarantees the whole chain of super constructor calls will finish before entering the body of a constructor, and all fields will be initialized. Thus by construction, virtual methods invoked on "this" won't see uninitialized fields. https://github.com/titzer/virgil/blob/master/doc/tutorial/Classes.md#initialization-order https://github.com/titzer/virgil/blob/master/doc/tutorial/Cl...
- zozbot234 2y ago
  You can most likely use session types to soundly observe a partially initialized MaybeUninit<MyObject> in Rust. The proper use of session types could ensure that the object is only assumed to be initialized after every field of it has been written to, and that no uninitialized fields are ever accessed in an unsound way. The issue though is that this is not automated in any way, it requires you to write custom code for each case of partial initialization you might be dealing with.

masklinn 2y ago

There are a few somewhat esoteric cases where constructors working in-place allow magic which can be hard to replicate otherwise e.g. Rust is still missing guaranteed “placement new” type behaviour. Unless you want to `ptr::write` individual fields by hand into a `MaybeUninit`, which you can absolutely do mind but that… is not very ergonomic, and requires structs to be specifically opted into this.

wongarsu 2y ago
Which can be an issue if you want to initialize a 2MB large heap-allocated object (e.g. heap-allocating a large nested struct or a big array). Without guaranteed “placement new” that can mean that your 2MB object gets constructed on the stack and copied to the heap. And while Linux defaults to a 4MB stack, Windows defaults to 1MB and will crash your program. Or it might work if the compiler optimizes in your favor. It's not something you encounter frequently, it can be worked around, and Rust will eventually solve it ergonomically without introducing constructor hell (probably with just a keyword). But finding the best language-level solution isn't straightforward (efforts to fix this for rust are ongoing for 9 years)
- bennettnate5 2y ago
  It can also be an issue if you want to wrap any API that requires fixed memory locations for objects (such as POSIX semaphores). It's UB to call a POSIX semaphore from any other memory location than where it was initialized, so making a `Semaphore::new()` API is just asking for trouble. You can deal with it by `Box`ing the semaphore, but then you can't construct the semaphore in a shared memory segment (one of the stronger use cases for process-shared semaphores). I have a hunch this is why there's no Semaphore implementation in the Rust standard library, though it could be due to fundamental inconsistencies in semaphore APIs across OSs as well ¯\_(ツ)_/¯
  - masklinn 2y ago
    No, Rust doesn't have semaphores in the stdlib[0] because it was not clear what precise semantics should be supported, or what purpose they would serve since by definition they can't mitigate exclusive and thus write access to a resource and mitigating access to code isn't much of a rust convention. And nobody has really championed their addition since. Furthermore, they still present a fair amount of design challenges in the specific context of Rust: https://neosmart.net/blog/implementing-truly-safe-semaphores-in-rust/ https://neosmart.net/blog/implementing-truly-safe-semaphores... [0] technically they were there, added in 0.4, never stabilised, deprecated in 1.7, and removed in 1.8

throwawaymaths 2y ago

I mean go's zero initialization requires a bit of language lawyering sometimes too. https://codefibershq.com/blog/golang-why-nil-is-not-always-nil https://codefibershq.com/blog/golang-why-nil-is-not-always-n...

chipdart 2y ago

> It’s been a while now, and at least in my experience so far Go and Rusts choice of not having special constructors really simplifies a lot. This take makes no sense. Think about it: you're saying that not having the compiler do any work for you "really simplifies things a lot". Cool, so you have to explicitly declare and define all constructors. That's ok. But think about it, doesn't C++ already offer you that option from the very start? I mean, you are talking about a feature in C++ that is not mandatory or required, and was added just to prevent those programmers who really really wanted to avoid writing boilerplate code to lean on the compiler in and only in very specific corner cases. If for any reason you want the compiler to do that work for you, you need to be mindful of the specific conditions where you can omit your own member functions. For the rest of the world, they can simply live a normal life and just add them. How is this complicated? Complaining that special member functions make obvious things less simple is like complaining that English is not simple jus because you can find complicated words in a dictionary. Yes, you can make it complicated if that's what you want, but there is nothing forcing you to overcomplicate things, is there?

tyg13 2y ago
You're mistaken. Rust does not require you to define all constructors. Rust does not have constructors. All structs in Rust must be initialized using brace syntax, e.g. `Foo { bar: 1, baz: "" }`. This is commonly encapsulated into static functions (e.g. `Foo::new(1, "")`) that act similarly to constructors, but which are not special in any way compared to other functions. This avoids a lot of the strangeness in C++ that arises from constructors being "special" (can't be named, don't have a return type, use initializer list syntax which is not used anywhere else). This combined with mandatory move semantics means you also don't have to worry about copy constructors or copy-assignment operators (you opt into copy semantics by deriving from Clone and explicitly calling `.clone()` to create a copy, or deriving from Copy for implicit copy-on-assign) or move constructors and move-assignment operators (all non-Copy assignments are moves by default). It's actually rather refreshing, and I find myself writing a lot of my C++ code in imitation of the Rust style.
- chipdart 2y ago