Erik Schnetter

Note that there is already a higher-level interface, modelled after Python's high-level MPI interface. For example, it's quite easy to send arbitrary objects to arbitrary processes.

(I didn't see this discussion earlier, and we discussed on Discord.) The earlier `MPI.jl` mechanism to figure out the ABI worked for about 95% of the ABI. The rest was...

For clarity: The build step would only be necessary if someone uses `MPI.jl` with an unknown MPI implementation, i.e. an MPI implementation that is different from MPICH, OpenMPI, Microsoft MPI,...

I don't think it's necessary to re-introduce this ability. There are other issues where our time is better spent. Apart from this, and for the record: The package [MPIconstants](https://github.com/eschnett/MPIconstants) does...

I guess `Put` shouldn't, but `Get` should, since it'll modify its argument?

Julia uses `put!` to put values into a channel. I concede.

This patch changes the default behaviour of `MPI.jl` to use `MPItrampoline_jll` as MPI provider. This will **break all Yggdrasil packages** that are built against `MPICH_jll`.

Yes, it seems the definition of `Recv!` lacks the `Ref` type; it only handles `Ptr` and `Array`. And yes, test coverage is lacking here. In your examples, the explicit conversions...

That should work, but is less efficient than changing the declaration of `Recv!` to include `Ref` as well: Change `buf::Union{Ptr{T},Array{T}}` there to `buf::Union{Ptr{T},Ref{T},Array{T}}`. (Untested; will look at it later today.)

Instead of using `@windows`, can we somehow detect which version of the MPI standard the MPI library implements? The non-blocking collective operations are all MPI 3, and since this standard...