Except that without implicit declaration, how do you bring constructor variance into check? For example, if you have an object/class that has a lot of options available, you would have to create a huge number of constructor functions, or other extensions to simply initialize an instance...
As I'm more familiar with JS than golang, it seems to me, with the current method, I can do something like...
var inst = new CustomObject(param1, param2, {
option15: 'bar'
,...
});
Where the first two parameters are required, but the last one can be a structure that represents available/optional options as a singular type... This would be much cleaner than supporting every variation of overloads as part of object construction. Let alone where a type can simply be used directly.
In Rust you usually use either method chaining (CustomObject::new(param1, param2).option15('bar')) or the struct update syntax (CustomObject { param1: param1, param2: param2, option15: 'bar', ..DEFAULT_CUSTOM_OBJECT }) for this. No extra complexity of "zero values" necessary (and the concept of a zero value would be incoherent in Rust anyway).
But you have either the complexity of multiple closures, or complex mutability (side effects) with that strategy, depending on how you approach your implementation. In either case the outcome could be less than ideal, and have more chance of unexpected results.
Is this...
var obj = new CustomObject(...);
...
obj.option15('bar');
The same as
var obj = new CustomObject(...).option15('bar');
IE: does calling option15 create a new closure/space that is separate from the original object (more functional separation) or does it mutate the original object?
I tend to prefer to limit mutations as much as possible in my code... it really just depends on your needs.
As I'm more familiar with JS than golang, it seems to me, with the current method, I can do something like...
Where the first two parameters are required, but the last one can be a structure that represents available/optional options as a singular type... This would be much cleaner than supporting every variation of overloads as part of object construction. Let alone where a type can simply be used directly.