Conceptually, a table can deal with rows that are a pointer type, and nullptr. We test for validity before accessing the row element, and can return gracefully from e.g. data() or setData(). This is also acceptable for lists, where a newly constructed row will hold a nullptr element as the item. Client code that wants to initialize new rows explicitly can provide their own protocol, or connect to rowsInserted() and rowsAboutToBeRemoved(). However, we might end up violating the requirement that in a table, all rows have to have the same number of columns: if the row-type is a pointer to a struct or gadget, and we don't instantiate the element, then we end up with an index that is de-facto invalid even though it is in range. setData() cannot do anything but return false, and data() can only return an invalid QVariant. And if the row type is dynamically sized, and the new row is inserted at index 0, then we end up reporting that the model has 0 columns, as we use row 0 as the reference for the column count. To fix this, implement new/deleteRow consistently for pointers (and smart pointers): if the row type is a (smart) pointer holding a default-constructible object, then we can instantiate a new object. The deleteRow implementation takes care of deleting raw pointers (as otherwise the `delete row` expression is invalid); for smart pointers, the smart pointer takes care of memory management. All other row types can be instantiated by default constructing. This covers MultiColumn/SingleColumn wrappers as well, which can hold a nullptr while still reporting the correct column count. Remove the special handling from canInsertRows() - if newRow() is available in the protocol, then we can insert rows. But one ambiguity remains: if we operate on a copy of a container that has pointers for rows, then adding new rows might allocate (in the model's copy), resulting in a mixed situation. The client code can not delete those new rows (they don't exist in the original container), while the model must not delete rows it didn't create (those do exist in the original container and might still be used). Perhaps that cannot be solved, other than by documenting: either move your range in the model (then ownership is clear), or pass a reference or pointer the model (then ownership is also clear); or use smart pointers for the row type. Change-Id: I18a2e929473d118dcdb9d1f2ed67a7890f681974 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>