While trying to implement this I encountered the following error when changing the signature of List.from in list.pony#L21 to fun from(that: List[A^] box) =>:

/home/theodus/stuff/ponyc/packages/collections/list.pony:26:12: argument not a subtype of parameter
      push(consume value)
           ^
    Info:
    /home/theodus/stuff/ponyc/packages/collections/list.pony:26:7: A tag is not a subtype of A iso: the subtype has no constraint
          push(consume value)
          ^
    /home/theodus/stuff/ponyc/packages/collections/list.pony:26:7: A box is not a subtype of A trn: the subtype has no constraint
          push(consume value)
          ^
    /home/theodus/stuff/ponyc/packages/collections/list.pony:26:7: A box is not a subtype of A ref: the subtype has no constraint
          push(consume value)
          ^
    /home/theodus/stuff/ponyc/packages/collections/list.pony:529:37: (A tag, A box, A box, A val, A box, A tag) is not a pairwise subtype of (A iso, A trn, A ref, A val, A box, A tag)
      fun values(): ListValues[A, this->ListNode[A]]^ =>

I'm confused about what the problem is and how it can be solved, especially since it works fine when that is a ref instead of a box.

Is that the only thing you changed @Theodus ?

It is the only change made to List.

We discussed on the call that there are compiler limitations that prevent this idiom from working as expected.

Action items (as I understand them):

• Adjust the new from constructor to take a type parameter for the input type, constrained by #read instead of being Object box.
• Use type parameter inference as described in Generic type inference rfcs#26 to make this less onerous.
• Adjust the compiler and/or type system to allow constructors to have their cap affected by the type parameter.
• Extend the compiler and/or type system to be able to loosen the requirement that iso, trn and val constructors have all sendable params, provided that we can prove some other points of safety, that @sylvanc can describe in more detail.

The idea is that the end result will be calling Foo.from(foo) where foo is a Foo ref will yield a Foo ref, and where foo is a Foo val will yield a Foo val, etc.

@jemc should we have new issues for the above action items?

@jemc did we ever discuss how:

Adjust the compiler and/or type system to allow constructors to have their cap affected by the type parameter.

would work and what the impact on existing pony code would be? would this be something that should be a request for RFC?

I think this would need a new RFC of its own, yes.