Structural Interfaces (not behavioral)

[zot]

I think it would be helpful if there were "structural interfaces" to express that a value is expected to have readable or writable fields of certain types when the value could also contain other fields (so the structural interface could be a subset of the value's type). Maybe something like Readable{x::Int, y::String} and Writable{z::Float64} (those names would probably clash with a lot of code that's already out there). This is a way to sort of embrace Julia's duck typing within the type system (it's no coincidence that TypeScript's interfaces can contain fields). This isn't like Java's interfaces because it doesn't address methods but I think it would provide some important utility.

This would let a function author indicate, "this function will fail if the input does not have an x::Int field," and IDEs could warn developers when they try to pass incompatible data to the function.

This could help document data used in protocols, file formats, etc. but still allow developers the freedom to use structures or named tuples which contain more information than the function uses.

As @quinnj points out below, Typescript's interfaces can contain fields (part of Typescripts "structural typing" concept) as well as methods. This proposal is just for interfaces with fields, not with methods. Typescript is probably what inspired this idea in the first place.

[JeffBezanson]

Very related: #4935

[zot]

True but structs and named tuples can be type compatible with many structural interfaces at once.

[iago-lito]

Would this be actually desugared to a behavioural interface with inlined get_field_x() -> Int and set_field_x(Int) methods?

[zot]

I don't think this should simply be sugar, I think it should be type information that can be checked with isa, etc. so that this:

structinterface AStructuralInterface
  a::Number
end

Guarantees that a exists in anything implementing the interface and

function foo(x::AStructuralInterface)
	println(x isa AStructuralInterface)
	println(x.a)
end

will work for any x that implements AStructuralInterface, printing true and the value of a.

[vtjnash]

Should we convert this to a "Discussion"?

[zot]

I certainly think it's worth discussing! 😃

[c42f]

This is interesting. It could be attractive to have generic dispatch with structural types for some uses. But there's some very thorny issues which come to mind.

• How would method specificity work for normal Julia types vs structural interface types if a function has both in the method table? Would we want some arbitrary but potentially useful rule like "structural types are always less specific"?
• Can multiple dispatch be made to work efficiently and sanely with structural typing? I guess structural types have a natural partial order so this helps?
• What about types which have an overloaded getproperty? From a user's point of view they may be members of some structural type, but the compiler won't know about that.

More generally, what about types where the fields aren't part of the public API? I guess the advice would have to be "don't pass those kind of types to functions which use structural dispatch". But this isn't very satisfying, especially given that methods could be added at any time.

[zot]

How would method specificity work for normal Julia types vs structural interface types if a function has both in the method table? Would we want some arbitrary but potentially useful rule like "structural types are always less specific"?

I think ambiguous cases ought to produce an error message like they do now

Can multiple dispatch be made to work efficiently and sanely with structural typing? I guess structural types have a natural partial order so this helps?

Not sure about this one

What about types which have an overloaded getproperty? From a user's point of view they may be members of some structural type, but the compiler won't know about that.

Perhaps there can be a way to assert that a type implements a structural interface when it cannot be inferred (something kind of like <:).

This could allow dispatching but leave it up to the developer to use getproperty/setproperty to implement it.

[c42f]

I think ambiguous cases ought to produce an error message like they do now

Sure. But is there a clear meaning for "ambiguous"? I feel like structural interfaces would be highly ambiguous by nature when combined with dispatch designed for the normal type hierarchy. For example

abstract structural type SomeStructuralInterface
    a::Int
end

abstract type AbstractBar end

struct Bar <: AbstractBar
    a::Int
    b::String
end

f(::SomeStructuralInterface) = ...
f(::AbstractBar) = ...

Is f(Bar(...)) ambiguous?

[zot]

I think ambiguous cases ought to produce an error message like they do now

Sure. But is there a clear meaning for "ambiguous"? I feel like structural interfaces would be highly ambiguous by nature when combined with dispatch designed for the normal type hierarchy. For example

abstract structural type SomeStructuralInterface
    a::Int
end

abstract type AbstractBar end

struct Bar <: AbstractBar
    a::Int
    b::String
end

f(::SomeStructuralInterface) = ...
f(::AbstractBar) = ...

Is f(Bar(...)) ambiguous?

I would say yes because both signatures match Bar.

Would there be a natural ordering of abstract types and structural interfaces? It doesn't seem intuitive to me...

I think this is similar to what happens in Java when a class implements two interfaces that both have default implementations for the same method signature. In this case, Java generates an error unless the class provides its own definition for that method.

For the f(Bar(...)) case, Julia could produce a method ambiguity error and the developer could define f(::Bar) to resolve it.

This does introduce a risk of developers creating ambiguity by adding their own methods to pre-existing functions but you can already do that in Julia by defining f(a, b::Int) when there is already a f(a::int, b).

You could say this is "more risky" because (AFAIK) you can't currently introduce ambiguity in Julia by picking a different type for the first argument when that's the only one whose type is specified for any of the methods of a particular function. But so much Julia code relies on multiple dispatch that I think this doesn't really increase risk in a practical sense.

[bauglir]

The given example does not necessarily indicate 'structure' to me. Readable and Writable sound like behavioral aspects of a type, as would something like HasFields. Especially given that this seems to mostly relate to how a type is being used at run-time in methods. One could probably argue that 'having a certain structure' is a behavioral aspect of a type.

From a type definition perspective this looks very similar to traits to me, of which there are already numerous (competing) implementations. The main complaint for these cases, as far as I'm aware, is the amount of boilerplate they introduce.

From a method definition perspective this seems related to pre- and post-condition on arguments, similar to what is implemented by something like DesignByContract.jl.

Those are both, to my knowledge, aspects that are more relevant to/evaluated at run-time and I can see how it would be beneficial to pull more of this information into the type system to make it statically available and being able to expose it to tooling, as well as being able to write these things down more succinctly (both of which are things I have been giving a lot of thought over the past couple of months, but don't really have anything to share for yet).

Adding structural 'inheritance' seems like a different aspect from what is being proposed here.

[zot]

In case the example is confusing, I made part of the original post bold to make it clear what is being proposed.

[zot]

The term "structural" is used here to distinguish from interfaces in languages like Java, Go, and Typescript, which describe what methods are expected to apply to a given type. Structural interfaces are about the fields/properties of an object, not about the methods which apply to it.

[quinnj]

The term "structural" is used here to distinguish from interfaces in languages like Java, Go, and Typescript, which describe what methods are expected to apply to a given type. Structural interfaces are about the fields/properties of an object, not about the methods which apply to it.

Just to clarify, the "structural" interfaces you've proposed are actually very similar to Typescript's interfaces, whereas Java/Go interfaces are more "behavioral" in that they deal with required methods for an object.

[zot]

You are right, Typescript's are like a superset of these and Go's/Java's -- I was thinking of the method parts of Typescript's interfaces, not the field parts.

[zot]

Typescript probably inspired this idea, too, since I've written a bunch of Typescript over the past couple years -- updated the first post to mention this.

[yuggoth-fungus]

Looks like @Keno's work on interfaces will handle this!

https://github.com/Keno/InterfaceSpecs.jl