I will try to summarize what I think we learned from our recent exercise.
The Swift compiler does allow one to use a single protocol in the above example, as long as one adds the mutating keyword to the protocol (as it was noticed by @zedthree and @septc).
My apologies to the Swift developers for having drawn a premature conclusion regarding this point. However, the fact that this keyword is required in the protocol itself still implies some knowledge by the protocol about the types that are going to (potentially) implement it.
Hence, the last two of my above-listed questions still stand, and with them the assessment that some languages do a cleaner job of separating implementation details from interfaces than others.
What we are seeing here, in particular regarding the presence of receiver objects in traits, is a continuation of the old philosophical divide between the Simula 67 and C++ influenced OO languages on the one hand, and the Smalltalk influenced ones (Smalltalk, Objective-C, Go) on the other.
The latter languages are (historically) known for their effort to cleanly separate interfaces (and messages) from implementations, while the former ones aren’t. The idea of protocols (and protocol inheritance, on which today’s traits are based) originated organically in the Smalltalk influenced languages, and was only later adopted by some of the Simula 67 influenced ones, which I think led to the minor inconsistencies that we now occasionally observe.
Go’s co-developer Robert Griesemer stated in this talk that Go’s interfaces are a translation, into a statically typed language, of Smalltalk’s way to do messaging. I think this is the very reason why Go, despite making use of explicitly passed receivers in implementations, was not misled into having the receivers appear also within interfaces. Go’s developers had a clear model in mind of how to do messaging cleanly (namely the way Smalltalk and Objective-C do it).
Hence, we’d better be looking into all these latter languages for guidance. This is why our design is fundamentally based on Go’s model to formulate its traits (see also our new Go version of the vector example in our Github repo).
Time permitting, I will further elaborate (with examples, in a later post) on the troubles and logical inconsistencies that pop up if one chooses to deviate from this model when designing a traits feature for Fortran – that, importantly, needs to include a facility for implementing traits by intrinsic types.