Open paulpdaniels opened 4 months ago
Also occurs in Scala 3
Moreover as long as you don't invoke a prune it will function correctly
This is the part that I'm finding most bizarre. I'm wondering whether this might be a legit bug either in how we do subtype checking in ZIO during pruning, or in izumi-tag
This is more of an aspirational issue as I'm not sure if this is actually fixable. At issue is the fact that
Newtype[A]
will fail at runtime if it interacts withZEnvironment#prune
.Consider:
This will fail with
Defect in zio.ZEnvironment: HashSet(TestApp::MyType1::Type, TestApp::MyType2::Type) statically known to be contained within the environment are missing
You can artificially make this work by explicitly providing a cast
EnvironmentTag
Moreover as long as you don't invoke a
prune
it will function correctly.for instance:
I suspect the issue arises because of how type tagging occurs. During creation of a layer we use the
derive
mechanism which is essentially justimplicitly[Tag[Wrapped]].asInstanceOf[Tag[Type]]
, this means that theLightTagType
that is inserted into the type map is that of the underlying type. In most cases theget
operation then uses the same mechanism, that is fetching by the underlying type id. However, in the prune case it is generating an intersection type via macro which seems to hold onto ephemeral type of the newtype instead. Hence, when it iterates through the set of environmental types it can't find them (because it isn't referencing the aliased type anymore). This is just a suspicion though, I don't have enough experience with the internals of this to say for certain.If this is actually an impossible ask, I would suggest adding a disclaimer to the docs indicating that newtypes aren't usable in this fashion, since this particular issue occurs at runtime.