Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members

[Eric Blake]

On 11/21/19 1:46 PM, Markus Armbruster wrote:

> > > The '*' is redundant in this form.
> > >
> > > Can anyone think of reasons for keeping it anyway?  Against?
> >
> > Is there ever a reason to allow an optional member but without a
> > 'default' value?  Or can we just blindly state that if 'default' is
> > not present, that is the same as 'default':0/'default':null?
> >
> > Or, applying your statement further,
> >
> > 'data': { '*a':'int', '*b':'str' }
> >
> > is shorthand for:
> >
> > 'data': { 'a': { 'type':'int', 'default':0 },
> >            'b': { 'type':'str', 'default':null } }
>
> You propose to default 'default' to a type-specific value.
>
> I don't think that's a good idea.

...


> When an absent member behaves just like it was present with a certain
> value DFLT, we want to be able to say in the schema 'default': DFLT.
>
> But the schema language also needs to let us say "absent member behaves
> unlike any value".
>
> If we define 'default' to default to a value, then that value must have
> this special meaning.
>
> Where that value is also a valid value, the schema language cannot
> express "absent member behaves like it was present with that value".
>
> I think this makes 0 a poor default value for 'default': "behaves like
> member was present with value 0" is fairly common, I think.
>
> Defaulting 'default' to null regardless of member type could work.
>
> null is a valid value of the 'null' type and of alternate types with a
> member of type 'null'.  For optional members of such types, the schema
> language then can't express ""absent member behaves like it was present
> with value null".  I think the need to say that is much less common than
> the needs to say "like value 0".
>
> Checking...  *sigh*: there are a few optional members that can take null
> values, e.g. MigrateSetParameters member @tls-creds.  I read its doc
> comment twice, and I have to admit I can't make heads or tails of it.
> Can't say for sure whether absent behaves like null, or some other
> value, or unlike any value.
>
> QAPI/QMP introspection already specifies null to have exactly this
> special meaning.

Maybe that means we need '*name':'t' to expand into something longer, maybe
 'name':{'type':'t', 'optional':true}
which in  turn would be synonymous with your idea of ALL types accepting 
a default of null:
 'name':{'type':'t', 'optional':true, 'default':null}

At any rate, your counterpoint is taken - whatever we pick, we'll want 
to make sure that introspection can expose semantics, and whether we can 
make '*' redundant with some other form of longhand in the qapi language 
is in part determined by whether we also reflect that through 
introspection.  If that means that keeping '*' in the longhand form of 
optional members (whether or not those members have a default value), 
then so be it.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org