Max Reitz <mre...@redhat.com> writes:
> With this change, it is possible to give default values for struct
> members, as follows:
>
> What you had to do so far:
>
> # @member: Some description, defaults to 42.
> { 'struct': 'Foo',
> 'data': { '*member': 'int' } }
>
> What you can do now:
>
> { 'struct': 'Foo',
> 'data': { '*member': { 'type': 'int', 'default': 42 } }
The '*' is redundant in this form.
Can anyone think of reasons for keeping it anyway? Against?
> On the C side, this change would remove Foo.has_member, because
> Foo.member is always valid now. The input visitor deals with setting
> it. (Naturally, this means that such defaults are useful only for input
> parameters.)
>
> At least three things are left unimplemented:
>
> First, support for alternate data types. This is because supporting
> them would mean having to allocate the object in the input visitor, and
> then potentially going through multiple levels of nested types. In any
> case, it would have been difficult and I do not think there is need for
> such support at this point.
>
> Second, support for null. The most important reason for this is that
> introspection already uses "'default': null" for "no default, but this
> field is optional". The second reason is that without support for
> alternate data types, there is not really a point in supporting null.
>
> Third, full support for default lists. This has a similar reason to the
> lack of support for alternate data types: Allocating a default list is
> not trivial -- unless the list is empty, which is exactly what we have
> support for.
>
> Signed-off-by: Max Reitz <mre...@redhat.com>
