Safe API for low-level h5 ids & ability to open objects from id
Currently, getID() returns an ID with the raw type h5id_t. Besides being against the convention of wrapping internal types, the reverse operation (opening object from ID) would be unsafe.
It would be useful for some advanced scenarios to allow the user to get or create a typed ID, which can then be used to open the real object. E.g.
H5GroupID gid1 = group.getId();
H5DatasetID gid2(123);
auto g = H5Group(gid1); // ok
auto g = H5Group(gid2); // compilation error
Note: this Issue has been created following the discussion in #400
I feel these are useful when interfacing with other libraries that aren't aware of HighFive. Therefore, I'm not sure about the value of a H5GroupID. The problem is that it's a type specific to HighFive. Libraries that don't know HighFive will work with something else, e.g. hid_t. Hence, they'll delay converting their hid_t to H5GroupID until they reach the software layer that bridges the two libraries, at that point they also know about HighFive::Group. There's very little difference between a H5GroupID and a HighFive::Group. Other than the rules surrounding reference counting. So unless we find need for a raw ID to behave differently from a HighFive::Group in terms of how it copies and moves, I don't see what we gain.
The other part: creating a HighFive::Group from a hid_t, seems very interesting. Here, the difficulty is to know if we need to increment the HID, and how we make this clear in code. (Borrowing and stealing is nomenclature I see used sometimes.) I think we can check that a given HID has the correct type (at runtime).
Finally, changing the return type of getId(). We need it to allow users to escape HighFive-land and use HDF5 directly. To me it seem reasonable that getID() returns a hid_t.