Should I interpret the adjective “material” in its Marxist sense (as in dialectical materialism)? I ask this, because since it seems to be a request from JaneStreet, this interpretation will make sense.
By the way, in the rationale of the PR, talex wrote:
This is a great improvement, but unfortunately a possibility hidden in the API. For instance, for the flow capability, you have to look inside the Eio.Flow.Pi submodule and use one of the smart constructors sink, source, shutdwon or two_way. I consider this a bad designed API. I would have prefered that this submodule was inline at the top of the Flow API documentation, for the very good reason that it is the mere definition of what a flow is (and therefore it is the first thing that one should read when reading the documentation). But instead we have a long list of non sensical definition of polymorphic variant, that are just here to serve as tags for the phantom type of 'a Result.t, tags used to preserved row polymorphism when an object is implemented as an existential GADT.
But, you can still have this way to implement your own resources and implement an object (that’s what a 'a Resource.t is) with the built-in OCaml object. That’s exactly what I explained to someone who wanted to emulate an object system without using the built-in one.
By the way, in the different way I present to emulate an object, Eio choose the GADT version and they add a polymorphic variant tag to preserve row polymoprhism. But doing so, they broke some guaranty. With plain OCaml object, when you have a function with this interface:
foo : #sink -> ...
it is in fact equivalent to a function with this one:
foo : (module S : Flow.Pi.Sink) -> S.t -> ...
and, thanks to Wadler’s theorem for free, I’m sure that foo can’t read its sink value.
But, now, with the new Eio API, if I have foo with this signature:
foo : _ sink -> ...
I have lost this guaranty. Indeed, if I pass it a _ two_way value I can’t be sure anymore that foo will not access the method in the Flow.Pi.TWO_WAY module used to construct my value, since foo can use Resource.get_opt under the hood, and it is not reflected on its type : I have to read its code to trust it. I consider this a privilege escalation and, as such, a security issue.
@avsm : don’t you consider this a problem? especially if we also consider the fact that the implementation of the Resource module must make use of Obj.magic.