(In reply to comment #0)
> it would be nice if GObject would support failing object instanciation and
> property getters/setters. There are many cases where object instanciation
> should fail directly and some libraries are using custom _new() functions that
> handle this (and OTOH these _new() function seem to cause problems for C++
> bindings and of course cause problems when creating subtypes).

I don't think this is a good idea. If people really need to conditionalize object creation, they should do so *before* calling g_object_new(). I don't see other languages providing gracefull failure mechanisms for object creation or object asignments either. C++, Python, etc may throw exceptions at any point in time, so also when creating objects, setting properties or initializing parent classes, but they also provide mechanisms to deal with the fallouts of exceptions  at multiple (call-)levels. C and libgobject simply do not. We will definitely not add mechanisms resembling exception handling to C (simply because it's not reliably doable for portable and cross-library usages) and we will definitely not pull the semantics of all existing calls to g_object_new() (google code search yields 80000+).
 
> This could be implemented by passing a GError to g_object_new() and
> g_object_set/get(), the former should also return NULL in case of error.

This would mean an incompatible change to the signature of very basic functions that are in very wide use, so this is technically not viable.
If something like this was implemented at all, libgobject would gain a new function anyway, e.g.:
  GObject* g_object_try_new (..., GError*);
Possibly accompanied by a new method that checks if object creation is possible (or auto-clean up of partially constructed objects). This kind of alternate constructor can be implemented for derived classes as well though, so there's no need to put this into libgobject itself, especially not for a feature that's unlikely of wide use. Or unlikely to be widely supported (most objects always can be created, so it'd be useless to force most object_new callers to check for errors that don't happen).

I don't think that changing the semantics of g_object_new() by this in 3.0 is a great problem. Or do you plan to make GLib 3.0 API/ABI compatible with 2.X? :)

Also, "people" are conditionalizing object creation already in custom foo_type_new() functions but apparently other's, like the Gtkmm guys, can't simply call these _new() function but instead need the same functionality when calling g_object_new() for creating subclasses. And the Gtkmm guys want to have initializer functions just because GLib doesn't support failing object creation...

I don't see the problem that could be caused TBH. If g_object_new() could fail or even g_type_create_instance() it would simply need to check that for every subtype the instance init (and in case of GObject ::constructor) doesn't fail. If it fails for a type the finalize/dispose functions would be called on the half-instanciated objects and clean stuff up (of course they must be written with the case in mind, that the object is not completely instanciated yet).

For property getters/setters this is even easier as a property is only set in a single type.

Sorry, I don't see why this is impossible to implement with minimal semantics changes in 3.0.

Please leave the bug resolution alone. It's up to the developers of a project to decide upon the fate of their project's bug states.

(In reply to comment #2)
> I don't think that changing the semantics of g_object_new() by this in 3.0 is
> a great problem. Or do you plan to make GLib 3.0 API/ABI compatible with 2.X?
> :)

API compatible, yes.

> I don't see the problem that could be caused TBH. If g_object_new() could fail
> or even g_type_create_instance() it would simply need to check that for every
> subtype the instance init (and in case of GObject ::constructor) doesn't fail.

All existing callers have to be aware of a possible NULL/error return as well, and that'd be prohibitively expensive, as i described in Comment #1 already.

> Sorry, I don't see why this is impossible to implement with minimal semantics
> changes in 3.0.

If you believe in the broad usefulness of you approach, i suggest you start out an addon library based on libgobject. E.g. YournamespaceVolatileObject that derives from GInitiallyUnowned and implements mechanisms for failing object construction and failing property setters. The GObject API allows for a full reimplementation of the setter/getter and creation functions on top of it, and people writing code based on VolatileObject will know from the start to take care of partial initializations in dispose/finalize, and to check the error state of constructors and setters. If that library proves to be widely usable and serves multiple projects, we can consider GLib integration of it once it's matured.