Yes, this is the major issue. When do you check for interface compatibility, and how? If you check for interface compatibility immediately then it will always f

Yes, this is the major issue. When do you check for interface compatibility, and how? If you check for interface compatibility immediately then it will always fail because methods will be defined after the struct. Do you check when the module definition is then completed? Maybe another module completes the interface definition: do you disallow that? This question becomes more subtle with multiple dispatch. If you have a type parameter, A{T}, you may only define the iteration protocol on A{T <: Number}, but the struct definition may allow any T. Should that error? So then if you error if the interface is incomplete at the bottom of the module, should you error if there exists any possible dispatch that is missing an interface function? Maybe the answer is then to error at the bottom of the module if there exists any type parameter that does not implement this interface. Okay cool, that does sound sensible. But now let's take a case where A{T <: AbstractFloat} defines the interface by doing direct dispatches for every floating point type in Julia Base. It won't error because iterate(::A{Float32}), Float64, etc. are all defined. Now someone adds the package ArbFloats.jl. Do you error when `using ArbFloats` because the interface is now not satisfied for `A{ArbFloat64}`? That would be annoying for users who never use type A, but if you don't error then your interfaces are not guaranteed to work. This would mean interfaces should only ever be used with `A{T <: T2}` where all interface definitions are done with `iterate(A{T}) where {T <: T2}` in the generic form so that it automatically extends well. That would be good code, but does that mean you should enforce that `iterate(::A{<:AbstractFloat})` is defined and error if it's not, even if every `T <: AbstractFloat` case is handled in the current REPL? There's a lot to think about. But no matter how that's done, I cannot see it not breaking some code somewhere, hence probably being a 2.0.