Object-Entity Mapping (OEM)

[shaobo-he-aws]

Rendered

[john-h-kastner-aws]

produces an entity uid unless the type is annotated with the #[cedar(transparent)] clause

I would rather see this made more explicit. E.g., #[cedar(record)] or #[cedar(entity)], perhaps with the entity case being assumed by default.

This could also support a nice syntax like #[cedar(long)] struct MyLong(i32) for wrapper types that might exist.

[khieta]

Thanks for the writeup @shaobo-he-aws! I think this looks like a useful addition to Cedar, but I disagree that it should be an RFC. It's a change to the Rust API rather than the Cedar language, so I think it should remain as an issue in the cedar repository. Maybe you could move the details here into cedar#986?

How do others feel about an RFC vs. issue here?

[shaobo-he-aws]

Thanks for the writeup @shaobo-he-aws! I think this looks like a useful addition to Cedar, but I disagree that it should be an RFC. It's a change to the Rust API rather than the Cedar language, so I think it should remain as an issue in the cedar repository. Maybe you could move the details here into cedar#986?

How do others feel about an RFC vs. issue here?

I'm afraid that moving it to an issue reduces discussion and eventually makes it buried in the backlog list.

[cdisselkoen]

It's a change to the Rust API rather than the Cedar language, so I think it should remain as an issue

We've previously done RFCs for other major changes that aren't technically changes to the Cedar language itself, for example, RFC 32 and arguably RFC 8. Similarly, I think there is consensus that partial evaluation itself would have been an RFC except that its development predates the RFC process. I think that this is a major enough change that an RFC is warranted, and particularly since @shaobo-he-aws has already gone to the trouble of writing one up, I think it makes sense to treat it as an RFC. If we didn't already have an RFC writeup and the primary author was pushing hard to keep this an issue instead of an RFC, I could see us maybe making a different decision on RFC vs issue, but since in this case the primary author is welcoming the RFC process, I see no reason to deny that.

I'm afraid that moving it to an issue reduces discussion and eventually makes it buried in the backlog list.

Even getting an RFC accepted (into Active state) does not promise any particular implementation priority, and the resulting implementation issue could easily get no discussion and become buried in the backlog, like, for example, RFC 53, where it took almost 3 months for the implementation issue to even be made. The RFC process isn't a magic way to get implementation prioritized, vs any other issues in the backlog. See the RFC life-cycle.