Could metaobjects support implicit interfaces/structural typing?

[rrousselGit]

One proposal is metaobjects

And to use this feature, objects have to implement a "static interface":

abstract class Decodable<T> {
  T fromJson(Map<String, Object?> json);
}


class Person static implements Decodable<Person> {
  @override
  factory Person.fromJson(Map<String, Object?> json);
}

This is cool! But having to implements the interface is very inconvenient.
In particular, having to implement an interface makes it difficult to support objects that we have no control over.

Imagine the following code:

abstract class Empty<T> {
  T empty();
}

T example<T static implements Empty<T>>() => T.empty();

Then even though List.empty() or Stream.empty() exist, we cannot do example<Stream<int>>().

---

Could this be solved by introducing a different kind of interface? One that is implicitly implemented by all objects which match its prototype?

Consider:

struct Named {
  String get name;
}

We could support:

class Person {
  String name = '';
}

print(Person() is Named) // true

This would enable changing our previous Empty example to:

struct Empty<T> {
  T empty();
}

example<Stream<int>>(); // OK

---

Going further: Should static extensions integrate with structs?
A separate proposal is about static extensions

A common use-case for this is to add new constructors on a class.
For example, adding a DateTime.fromJson:

static extension on DateTime {
  factory DateTime.fromJson(int json) => ...
}

DateTime.fromJson(0000);

It would be great if static extensions could combine with structural typing, such that we could have:

static extension on DateTime {
  factory DateTime.fromJson(int json) => ...
}

struct Decodable<T> {
  T fromJson(Object obj);
}


void example<T static implements Decodable<T>>() {}
example<DateTime>();

[RohitSaily]

Definitely would benefit from this. I often find myself wanting to make types from outside a codebase work with some interface from within the codebase and unfortunately the direct-most solution I can think of, that keeps static checks, are boilerplate wrappers which just add more indirection.

Going further: Should static extensions integrate with structs? [...] It would be great if static extensions could combine with structural typing

Yes, I agree static extensions should be able to satisfy structural type requirements. Especially since a type external to the codebase may be effectively usable as a structural type but just never had the appropriate interface defined for it.

I have also had situations where I wanted to define an interface that enforced static members but could not because it is not possible with the current feature set.

---

To add, the ability to define default implementations for structural types would be useful. This can allow the structural type to automate implementation of its API and just let conforming types fill in the necessary parts.

struct PointOccupant
{     ({num x, num y}) get coordinate;
      num slope(PointOccupant other)=>
           (other.coordinate.y-coordinate.y)/(other.coordinate.x-coordinate.x)
}

Ideally types could also explicitly conform to structural types and refer to its members (via super?, without interfering with the ability for inheritance, mixins, etc) so it can customize implementation where it needs to.

Also would be great to allow conformance via regular extensions and extension types with the use of redeclared members (@redeclare) within a code base so code external to the code base can be customized in how it implements structural types if it already does.