first what is triff?

second we don't have tuples just structs.  They aren't dynamic.  A signature of
() means it always has to be empty which I don't belive is legal though the spec
doesn't say one way or the other.

tuples are structs

triv is the type of the empty structure (ie: structure containing zero items)

triff is the only possible value of that type (sort of like how there is only
one possible string of length zero - "")

they are both (the type and the value) written as () in languages like haskell.

from talking on irc, rob seems to think that the spec actually allows empty
tuples (or structs as you say).  where structs are introduced in the spec there
is never any statement that certain cases (like empty structs are outlawed).

this is valid C, btw:

struct foo {};

:)

This is probably pretty simple to add (may be a matter of deleting code that 
disallows it, more so than adding code). 

Question I'd ask is how many existing language bindings would choke on it...
you can do this in C maybe but it isn't useful/sensible afaik... I would 
expect python allows an empty tuple... I don't know what the struct mapping is 
in Qt or Java bindings.

For the variant case, allowing a variant containing DBUS_TYPE_INVALID might be 
more sensible?

i imagine both measures are reasonable in their own ways.

just from a logical standpoint -- it seems weird to specifically forbid the case
of triv unless you have a specific reason to do so (like it causes certain
language bindings to break).  zero is just as good of a number as 2 or 3.  it
should even be possible (albiet odd) to have functions that take zero-tuples as
first-order arguments (ie: outside of variants).  i can't imagine why anyone
would want to do this but it makes sense for purposes of being consistent.

allowing the sending of the 'invalid' type in a variant is a bit less logically
sound since it's not possible to send this outside of a variant directly on the
wire as itself (since, for example, this type is often used to terminate lists
of types of arguments).  you could never have a function that takes an invalid
as an argument.  if anything, this should be seen as a workaround.

the more i think about this problem it comes down to the fact that dbus has no
equiv to G_TYPE_NONE (ie: the 'void' type).

the idea of using triv just makes sense since functional programming languages
that don't have a void type either (why would a function return void??) use triv
to replace void in cases where returning void really *does* make sense (like in
a monad).

If the D-Bus protocol forbids empty structs (and since the reference implementation of the bus daemon will disconnect you if you send them, the only safe assumption is that it does), the spec should say so. Attaching a patch.

Created attachment 11954 [details] [review]
patch to dbus-specification specifically forbidding signature '()'

Perfect, thanks. (commit at will)

This was committed three years ago this week: bf7c65f5218d07734bcc7be373ebc33278806824