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.

[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! 😃