I don't agree that MPI::File is not an acceptable scope
for the open call; MPI::Datatype works fine as a scope for
all the datatype constructors, even though the datatype
object doesn't exist when the functions are called. (Presumably
these are static member functions.) If one wanted to follow
the rules to the letter, I suppose MPI::File::create would
be acceptable. Unfortunately, "create" already means something
else in the context of file manipulation.
While MPI_Comm_open_file may be consistent, I don't
think it's intuitive, and in my opinion the main reason to
worry about consistency at all is that it makes the names
easier to understand and predict. MPI_Open is already a
name that's easy to understand and predict, so we don't
need to mess with it. What's more, I think we would get
far more complaints from users about a name like
MPI_Comm_open_file than we ever would about MPI_Open.
As for using "File" in names like MPI_File_read_explicit_all,
I would point out that Rule 2 explicitly permits the object
to be omitted from the C and Fortran names if the operation
can only be applied to one object. Thus MPI_Read_explicit_all
is completely legal.
John