object/struct default initialization

[i3dmaster]

I am not sure if this has been discussed before but the general idea
is that in struct definition, the language should support specifying
default values for fields. It is somewhat default initialized anyway
in Go just that for now, everything gets initialized to either 0 or
nil. Consider the following code:

type MyStorage struct {
path string
max_retry int
op *Operation
}

It would be nice if I can write in this way instead:

type MyStorage struct {
Path_info string = '/my/default/path'
Max_retry int = 3
Op *Operation
}

In struct construction, I then only need to provide the Operation
object and the rest would be initialized to default as s := MyStorage
{op: new(Operation)}

If field values are provided during construction time, then the
default values will be overridden. Such as
s := MyStorage{path_info: '/foo', max_retry: 10, op: new(Operation)}

The compiler does not need to alloc storage during the type definition
even if default value is provided, it only needs to remember them and
later, if no values provided, allocate the memory and store the
defaults.

It will not only save tedious typing time if one constructs a lot
objects with most fields apply only defaults and just some needs to be
overridden but also helps code refactoring in the future (no changes
to the object initialization code if fields added have default values
and only those that those fields need to be initialized to different
values)

I'd like to see others opinions.
Thanks.

[Ian Lance Taylor]

i3dmaster <i3dm...@gmail.com> writes:

> I am not sure if this has been discussed before but the general idea
> is that in struct definition, the language should support specifying
> default values for fields.

You can get a similar effect by writing a function which sets the
fields to the defaults. Also, in general the language encourages
thinking of the zero value as the uninitialized value. This feature
would be occasionally handy but I'm not sure it buys us much.

Ian

[Russ Cox]

You can get a similar effect by writing a function which sets the

fields to the defaults.  Also, in general the language encourages
thinking of the zero value as the uninitialized value.  This feature
would be occasionally handy but I'm not sure it buys us much.

Just to expand what Ian said, the zero value as the default is

a simplifying assumption, in the best sense.  It is occasionally

inconvenient but in exchange completely avoids discussion of

constructors, recursive constructors, partially constructed objects, etc.

The zero value is one of my favorite small features in Go.

Russ

[Yongjian Xu]

Yes, I am all for the default initialization to zero feature. I do like it too and actually, it is because of this feature had me thinking that why we should just force it to zero. Why not give the ability to programmers to set defaults to the values they want? The object construction should almost stay the same. The only change would be if a default value is given, use that, otherwise, still initializes to zero. Still no ctor required, no partial initialized objects, etc, etc...

[Yongjian Xu]

The problem is often code is written by different people and maintained by different people and it is often not future proof. Extending the code often involves a quite bit of refactoring or tedious signature changes. It is probably perfectly ok one had written new(Foo) or Foo{} that initialized the object fields all to zero, but its hard to guarantee that's always the case. Imagining there is a already written struct with

type Foo struct {

   field1

   field2

} 

and get constructed all over the code base by new(Foo) and/or Foo{field1: 'something'}, Foo{}, etc... Introducing an additional non-zero field would mean to change all the occurrences of the object constructions. If default value is allowed during the field declaration, then all the rest of code could be intact or just the onces that require a different values need to be changed. I think the code essentially becomes

type Foo struct {

   field1 = 0

   field2 = 0

   field3 = 10

}

Where "= 0" can be syntactically eliminated because Go does it for you and only specify the ones with non-zero / non-nil values, which becomes

type Foo struct {

   field1

   field2

   field3 = 10

}

Does this require a huge change in the compiler?

[Russ Cox]

On Tue, Jan 12, 2010 at 10:51, Yongjian Xu <i3dm...@gmail.com> wrote:
> Why not give the ability to programmers to set
> defaults to the values they want?

because that gets rid of the "simplifying" part of the simplifying assumption.
defining the zero value to be non-zeroed memory would require
introducing per-field initializations that do not happen right now.
right now, zeroed memory is ready to use right away without any work.
you are proposing to change code that does not exist.

russ

[Marcin 'Qrczak' Kowalczyk]

2010/1/12 Russ Cox <r...@golang.org>:

> Just to expand what Ian said, the zero value as the default is
> a simplifying assumption, in the best sense.  It is occasionally
> inconvenient but in exchange completely avoids discussion of
> constructors, recursive constructors, partially constructed objects, etc.
> The zero value is one of my favorite small features in Go.

It may simplify the language specification but it definitely does not
simplify using the language. Depending on implementation details the
default value of some type may be valid or not, and this decision
cannot be easily changed. This is one of the worst Go misfeatures.

--
Marcin Kowalczyk

[Andrew Gerrand]

Can you provide an example of this?

It would seem that a zero default value (as in Go) is more useful than
an undefined default value (as in C). If you require some other
initial state, isn't it prudent to set that state explicitly? (Rather
than extending the language to support arbitrary default values.) Or
am I misunderstanding the nature of your grievance?

Andrew

[Steven Blenkinsop]

Why can't you just use a constructor "func NewT() *T {...}"? Its not
more complex, and allows for more thorough initializations. One issue
is that you'd have to use the reflection interface to allow optional
parameters to construction, or export methods/fields that allow the
user to tweak the state after construction (as is common in GUI
libraries) if that is sufficient. If you want to disallow invalid
instantiations, you can encapsulate the type to prevent the default
zeroed initializations.

Anyway, as you demonstrated, your proposal doesn't completely cover
the need you described. Maybe a better approach would be coming up
with a way that simplifies flexible construction rather than tackling
default initialization. Reflection doesn't exactly make for the
prettiest code...

[Marcin 'Qrczak' Kowalczyk]

2010/1/13 Andrew Gerrand <andr...@gmail.com>:

>> It may simplify the language specification but it definitely does not
>> simplify using the language. Depending on implementation details the
>> default value of some type may be valid or not, and this decision
>> cannot be easily changed. This is one of the worst Go misfeatures.
>
> Can you provide an example of this?

Any object containing a map.

If it didn't contain a map before and its clients relied on zero
initialization, and now it does contain a map, then every method must
face the possibility that the map has not been initialized yet. It is
impossible to ensure that any instance of that type contains an
initialized map and still allowing clients to embed it in other
objects by value.

> It would seem that a zero default value (as in Go) is more useful than
> an undefined default value (as in C).

I'm not defending the C semantics.

> If you require some other
> initial state, isn't it prudent to set that state explicitly?

If it's other than the default, then it should be stated explicitly.
But the default should not be limited to all-fields-zero; the type
should decide how to make a default instance if a default instance for
it makes sense at all.

--
Marcin Kowalczyk

[Marcin 'Qrczak' Kowalczyk]

2010/1/13 Steven Blenkinsop <stev...@gmail.com>:

> Why can't you just use a constructor "func NewT() *T {...}"?

Mutex doesn't. I want a type which is as convenient to use as Mutex,
but without constraining the implementation to have all-fields-zero as
a valid and default value.

--
Marcin Kowalczyk

[Steven Blenkinsop]

So you're saying that:

m := new(Mutex)
or
var m Mutex

is easier than:

m := NewMutex()

?

[Russ Cox]

> m := new(Mutex)
> or
> var m Mutex
>
> is easier than:
>
> m := NewMutex()
>
> ?

yes, very much. because you can put a mutex in another
data structure and not worry about creating it separately.
having used other libraries with this property and then
had to move to C pthreads, i can attest that this is a huge
usability win. that's why Effective Go encourages making
the zero value a useful, ready to use value, no initializer
required. it's the major benefit of the simplifying assumption.

russ

[Ganesh]

On Jan 12, 8:09 pm, Ian Lance Taylor <i...@google.com> wrote:

The zero default initialization value often gets one trouble. The
problem I
ran into was a function call, where the function variable was only
default
initialized: and it terminated the program. I think what is proposed
is a
useful feature.

>> The zero value is one of my favorite small features in Go.

Yes, its useful in general, but it can get us into trouble. Using
typenames as variables, accidental use of :=, default intialization of
maps/functions etc... my list is growing. One day, I'll send the "Go
traps and pitfalls" list to this mailing list.

-Ganesh

[Rob 'Commander' Pike]

On 14/01/2010, at 11:16 PM, Ganesh wrote:

>
> On Jan 12, 8:09 pm, Ian Lance Taylor <i...@google.com> wrote:
>> i3dmaster <i3dmas...@gmail.com> writes:
>>> I am not sure if this has been discussed before but the general idea
>>> is that in struct definition, the language should support specifying
>>> default values for fields.
>>
>> You can get a similar effect by writing a function which sets the
>> fields to the defaults. Also, in general the language encourages
>> thinking of the zero value as the uninitialized value. This feature
>> would be occasionally handy but I'm not sure it buys us much.
>
> The zero default initialization value often gets one trouble. The
> problem I
> ran into was a function call, where the function variable was only
> default
> initialized: and it terminated the program. I think what is proposed
> is a
> useful feature.

Every reasonable feature is useful. That is not a sufficient criterion for inclusion. The question is whether the feature is useful enough to offset the cost it adds in complexity of specification, complexity of implementation, and overwhelmingly most important, the complexity of interaction with the existing features.

On the last point, this one is a loss. It interacts badly. The existing notion of a zero value carries a lot of weight for its simplicity and you propose to break that. Not a good plan.

-rob

[Shane]

I like the idea of 0 being the known baseline, consistent, initialised
state. +1 to leave as is.

-shane

[Yongjian Xu]

Hi Rob or Russ,

Can you guys elaborate a bit more on what exact complexity will be added into the current implementation (given most of language users probably don't actually know every piece of internals of the language itself but I'd curious how it would be implemented), and more interesting, what kind of obstacles for other existing features will be introduced if the feature is added? 

Keep in mind that this propose does NOT indicate removing the zero-initialization feature at all. That stands as default as usual. Rather it proposes to provide default value option to programmers so that zero initialization isn't the only choice...

Adding this feature should bring no regressions at all and most of the existing code should not need to be changed unless they intend to use different default initialization values.

I'd appreciate if you guys can given a bit more details.

Thanks,

Jim 

-rob

[Russ Cox]

> Can you guys elaborate a bit more on what exact complexity will be added
> into the current implementation (given most of language users probably don't
> actually know every piece of internals of the language itself but I'd
> curious how it would be implemented), and more interesting, what kind of
> obstacles for other existing features will be introduced if the feature is
> added?

The exact complexity is that where now the initialization is (in C)

memset(p, 0, sizeof *p)

the proposal would require significantly more code, generated on
a per-type basis. It's doable - everything is doable - but it
complicates what is now utterly trivial code that works very well
most of the time. One need only look to the many many pages
of rules that govern C++ initializers to see how utterly non-trivial
things can get once you start introducing implicit object
initialization.

Russ

[Ian Schumacher]

I know this is an old thread, but I wanted to add my 2 cents anyways.

For a modern language, not having some standard initialization mechanism seems kinda crazy. Right now it is being left up to developers to come up with their own adhoc initialization approach, i.e. a NewT() factory method, an init() method or just leave it up to the user of the code to fill in the struct fields manually ... and so on. Documentation is then left to fill that gap to explain how an object should be initialized. Adhoc approaches for common tasks == bad.

Obviously the go team ran into this problem themselves and thus had to come up with the somewhat inelegant 'make' solution. It should be clear that developers using the language will have the same problem. Maybe there could be a mechanism to allow make to receive user defined types as well (as an example of one solution)?

Go has garbage collection, but no 'object' initialization mechanism because that's too hard ... tell me that's not crazy.

[Thomas Bushnell, BSG]

The standard solution is actually to have the zero value be the initialized value.

And, to have factories which return objects rather than initiazations.

So you don't do this:

os.Open(filename, reader)

instead you do this:

reader = os.Open(filename)

Thomas

[Uriel]

On Sat, May 26, 2012 at 1:26 AM, Ian Schumacher
<ian.sch...@gmail.com> wrote:
>
> Obviously the go team ran into this problem themselves and thus had to come
> up with the somewhat inelegant 'make' solution. It should be clear that
> developers using the language will have the same problem.

I don't have the same problem, nor do I have heard any Go programmer
having that problem.

> Go has garbage collection, but no 'object' initialization mechanism because
> that's too hard ... tell me that's not crazy.

I don't think anyone claimed it is hard, it is just not very useful to
have an extra special "object initialization" mechanism when functions
work just fine for the task.

Also note how even other languages that have constructors only handle
some situations, but not always, and is why you end up with factories
and other such patterns.

This reminds me of another reason i love Go, in Python I always end up
having to type things like:

class foo:
def __init__(self, bar, baz):
self.bar = bar
self.baz =baz

So i can use foo(a, b) to create a new object.

While in Go I can do:

type foo struct {
bar int
baz string
}

And then foo{a, b} to create a new foo. Might seem similar, but I find
Go's style more clean and simple.

Note that in the Python version bar and baz appear *three times*, and
self is in every line, that is a lot of stuttering specially if you
have quite a few members. Go on the other hand is concise and there is
no redundant information (there is actually more information than in
the python version because it gives you the types of each element and
how they are structured in memory)

In short: Go handles the most common case much better, while when you
need special initialization, you always use a function, rather than
having yet one special kind of function which is called implicitly
somehow in certain cases. (That is another problem with constructors,
if often hard to know if code gets run when you create an object, or
if it will just initialize its fields to zero and that is it).

[Darren Grant]

On Fri, May 25, 2012 at 4:26 PM, Ian Schumacher
<ian.sch...@gmail.com> wrote:

> Go has garbage collection, but no 'object' initialization mechanism because
> that's too hard ... tell me that's not crazy.

Explicit memory management dominates most of my initialization and
termination code in non-GC'ed languages. With that out of the way I
have found strict initialization semantics to be barriers to
comprehension and design, so I don't think it's crazy.

The issue arises in GC'ed languages where the composition of other
systems requires explicit resource management. Maybe this is enough to
warrant the argument, I'm not sure. :)

[Thomas Bushnell, BSG]

On Fri, May 25, 2012 at 5:08 PM, Uriel <ur...@berlinblue.org> wrote:

Note that in the Python version bar and baz appear *three times*, and
self is in every line, that is a lot of stuttering specially if you
have quite a few members. Go on the other hand is concise and there is
no redundant information (there is actually more information than in
the python version because it gives you the types of each element and
how they are structured in memory)

Actually, the go version doesn't tell you how they are structured in memory.

Thomas

[Ian Schumacher]

Ok, all good replies.  Factories are a good approach ('make' then ... seems slightly out-of-line with factories as a go idiom for object initialization, but whatever)

Whatever, it seems the consensus is initialization isn't needed or wanted, and I can live with that. I need to revisit some of my code now and move to factories since I wasn't really sure what approach to take at the time and was doing init() instead.

[Uriel]

On Sat, May 26, 2012 at 2:20 AM, Ian Schumacher
<ian.sch...@gmail.com> wrote:
>
> Whatever, it seems the consensus is initialization isn't needed or wanted,
> and I can live with that. I need to revisit some of my code now and move to
> factories since I wasn't really sure what approach to take at the time and
> was doing init() instead.

The preferred approach is to make the "zero-value" usable, it works
really well in most cases, even if it sometimes requires some thought.

[Ian Schumacher]

Sure, but for anything complicated that's not possible.  For example any stuct that has a chan, slice, or map in it ... 

I guess you 'could' check the value inside any method that uses it and then initialize it there, but that seems kind-of messy I think.

[Ian Schumacher]

I thought factories where the standard approach - that's seeming less sure and back to my point ;-)  Whatever, I can do without it.

[Jesse McNelis]

On Sat, May 26, 2012 at 9:26 AM, Ian Schumacher
<ian.sch...@gmail.com> wrote:
> Go has garbage collection, but no 'object' initialization mechanism because
> that's too hard ... tell me that's not crazy.

Allocation is dead simple.
Initialisation in a general case is arbitrarily complex.
eg.
To initialise an os.File you call os.Open() which gives you a pointer,
but os.Open() can error so any code doing this initialisation has to
expect and handle an error.
To initialise a net.Conn you call net.Dial(), or you .Accept() on a
net. Listener.
These cases aren't simple to express in some general initialisation mechanism.

Some initialisers return pointers, some return interfaces wrapping the
object being initialised, others just return struct values.

The ability to have any number of initialisers, with arbitrary names
and arbitrary behaviour is a big plus.







--
=====================
http://jessta.id.au

[Patrick Mylund Nielsen]

You can append to nil slices, but you still have to make maps before you can use them.

On Sun, May 27, 2012 at 12:33 PM, Jiří Zárevúcky <zarevuc...@gmail.com> wrote:

On Saturday, 26 May 2012 02:28:45 UTC+2, Ian Schumacher wrote:

Sure, but for anything complicated that's not possible.  For example any stuct that has a chan, slice, or map in it ... 

I guess you 'could' check the value inside any method that uses it and then initialize it there, but that seems kind-of messy I think.

You will find that nil slices and maps behave pretty much the way you want them to, unless you need to fill them up before using. 

[Rodrigo Moraes]

On May 25, 9:24 pm, Uriel wrote:
> The preferred approach is to make the "zero-value" usable, it works
> really well in most cases, even if it sometimes requires some thought.

The problem happens with maps and channels, which don't have a "a
useful, ready to use value". Structs with them need an initializer, or
you may need to check if they are ready before use.

Not that big of a deal, but as pointed by others this is the case
where the zero-value is inconvenient and leads to some minor
inconsistencies ("that struct is usable without initializer, that
other is not").

-- rodrigo

[Patrick Mylund Nielsen]

Personally, I prefer simple having a New() function. If there is a New function, you know not to do s := TheStruct{} by yourself. It shows up right with the type in the docs, and you're free to make a New and NewBuffered if you want to. I would hate to be locked in by a "formal" type initializer, and it wouldn't really improve anything.

Sure, it might get inconsistent if people start giving the initializers different names, but I don't think this is the case. Virtually everyone uses New when a struct has some kind of setup requirement, or something like New32 and New64 when it makes sense.

I think the argument about some types being initialized and others not is valid, but as long as library writers provide a New(), this seems completely negligible to me.

[⚛]

On Saturday, May 26, 2012 1:26:56 AM UTC+2, Ian Schumacher wrote:

I know this is an old thread, but I wanted to add my 2 cents anyways.

For a modern language, not having some standard initialization mechanism seems kinda crazy.

As others have noted, the initialization rule in Go is that values are initialized to zero. This initialization rule is simple to remember and it solves the problem of safe initialization in the language.

 

Right now it is being left up to developers to come up with their own adhoc initialization approach, i.e. a NewT() factory method, an init() method or just leave it up to the user of the code to fill in the struct fields manually ... and so on. Documentation is then left to fill that gap to explain how an object should be initialized. Adhoc approaches for common tasks == bad.

The difference between writing new(T) in C++/Java and writing NewT() in Go isn't as significant as you are rendering it.

 

Obviously the go team ran into this problem themselves and thus had to come up with the somewhat inelegant 'make' solution.

How else would you create a channel of integers in Go without writing make(chan int)?

 

It should be clear that developers using the language will have the same problem. Maybe there could be a mechanism to allow make to receive user defined types as well (as an example of one solution)?

The mechanism you suggested wouldn't eradicate zero-initialization of values in Go.

 

Go has garbage collection, but no 'object' initialization mechanism because that's too hard ... tell me that's not crazy.

I am telling you: it's not crazy.

[Rodrigo Moraes]

Btw, what's the main reason for maps not having a usable zero-value?

-- rodrigo

[chris dollin]

On 27 May 2012 17:07, Rodrigo Moraes <rodrigo...@gmail.com> wrote:
> Btw, what's the main reason for maps not having a usable zero-value?

A copy of a map has the same behaviour as that map.
All zero-valued maps are equal.
Hence, if the zero value of a map were to allow update and
retrieve, any other zero-valued map would refer to the same
storage, ie all zero-value maps would share.

This is unlikely to be what anyone wants. So the zero-valued
map refers to no map at all.

This argument doesn't work with slices, because all copys of
a zero-valued slice /do/ behave the same, but slices also
have the append function available, which will create a new
slice with different backing store if necessary. Maps don't have
this (or a like) operation.

Chris

--
Chris "allusive" Dollin

[⚛]

On Sunday, May 27, 2012 6:07:16 PM UTC+2, Rodrigo Moraes wrote:

Btw, what's the main reason for maps not having a usable zero-value?

The main reason is that map insertion is unlike slice append. In order for nil map to be usable, map insertion would need to follow the same pattern as append.

[Steven Blenkinsop]

On Sunday, May 27, 2012, Rodrigo Moraes wrote:

Btw, what's the main reason for maps not having a usable zero-value?

You could make the map data type be the value maps currently point to, but then you'd have to make it illegal to copy maps and make map accesses require an addressable map or a pointer to a map. This seems more complicated than might be desired. I think I read that maps and channels used to be pointer types, perhaps like this, but this wasn't as usable, so it got changed to the current system.

[Maximo Cuadros]

Hi,

I just seeing this old thread, and i have the same behaviour in my code, so i choosed to make a library to enable default values in structs through the StructTags (please guys avoid the scream,  i just learning go):

type ExampleBasic struct {
    Foo bool   `default:"true"` //<-- StructTag with a default key
    Bar string `default:"33"`
    Qux int8
}

https://github.com/mcuadros/go-defaults

Regards

[DisposaBoy]

ignoring the educational value of this pkg... why not just make a factory function? with this it seeks to me that you lose flexibility and more importantly static/compile safety, etc. for...

[Máximo Cuadros]

Ok, if you have many settings in you application to be configured for
something like gcfg[1] you need to write down every default value in
this factory, in this way i can make another piece of code to generate
a doc with the documentation.

BTW where you lose the static safely? all the types are converted to
the correct ones, and the struct contains the proper types, similar to
any json unmarshal, the redis driver or the mongo ones.

This is not a general propourse library is just for some specific uses
cases like i have with gcfg



[1] https://code.google.com/p/gcfg/

On Tue, Jan 14, 2014 at 8:22 AM, DisposaBoy <dispo...@dby.me> wrote:
> ignoring the educational value of this pkg... why not just make a factory function? with this it seeks to me that you lose flexibility and more importantly static/compile safety, etc. for...
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/ZwXGldT4FOM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[DisposaBoy]

I used your example code and added some relevant changes and comments here http://play.golang.org/p/3hUE1Doq7g

[Máximo Cuadros]

Thanks!

Now is see your point, yes in the case of the values if you make
something wrong will be totally omitted. But as i said this is not a
general case and you will need to make tests of this struct to ensure
the correct setup.

About the factory of course i dont need it i just a example of usage.

Anyway i will take a look closer to this comments

On Tue, Jan 14, 2014 at 10:46 AM, DisposaBoy <dispo...@dby.me> wrote:
> I used your example code and added some relevant changes and comments here http://play.golang.org/p/3hUE1Doq7g
>