Sukera

> This does seem to be something that should be at a minimum fixed in the documentation. It is mentioned in the docstring: > The optional `esc` argument specifies any...

I still want to support this, yes, but the checking part for this is, in general, a bit tricky. Consider this type for example: ``` struct MyVector{T} Base.return_types(getindex, (MyVector, Int))...

Keywords are a bit tricky; the way they're handled by Julia is pretty internal, especially when it comes to required/optional keywords. For example: ```julia julia> struct Foo end julia> (f::Foo)(a;...

This can get complicated very quickly. Should `my_other_func` error when it encounters a `MyType{Int}`, for example? This is not an issue in the current implementation, because `@required` doesn't handle `UnionAll`...

Yes, that is intentional - an interface cannot really have optional methods. In your example, I'd be open to add something like ```julia abstract type MyType{T} end @required MyType begin...

Great! I'll leave this open, since support for `UnionAll`-style child interfaces seems intriguing.

That's a very good list! I have the "you get these methods" part of interfaces implemented on a branch, but it's not yet merged into main. Still needs some tests!...

Of course - the "you get these methods" list is purely intended as a "we guarantee to support at least these calls", not as an exhaustive list of what technically...

The syntax is `a=Data.Floats()`, not `a::Data.Floats()`; i.e. you're assigning/setting `a` to use elements from `Data.Floats()`. It's not a type assertion, because `Data.Floats()` is not a type, and you can reuse...

> My previous — obviously wrong — understanding was that the Julia compiler was trying to guard us from LLVM's undefined behaviors via freezes and such. That is not so...