Class cycle operation metadata for languages without GC

[bernardnormier]

In programming languages without GC, such as C++ and Swift, Ice's default behavior should be to reject during unmarshaling operation parameters and return values that create cycles.

Then, if an application needs to accept such class cycle, it should add metadata to the operation to instruct Ice to accept such cycles during unmarshaling, e.g.

 // in params can contain a cycle
[cpp:accept-class-cycles] void op(Person p1, Person p2);

// in params or return value can contain a cycle
[swift:accept-class-cycles] AnyClass op2(AnyClass a); 

The proposed metadata would affect only unmarshaling (hence the accept prefix). There is no particular reason to disallow cycles during marshaling.

[pepone]

It doesn't feel like configuring accept/deny cycles per operation would be that interesting. Using ClassGraphDepthMax should be enough for most use cases.

[bernardnormier]

On the contrary, I think it's desirable to make this choice per operation. The default (for GC languages) is to NOT accept any cycles, but you may want to accept cycles for one or a handful of operations ... and then implement these operations with this knowledge (i.e. break the cycles "by hand").

Currently, the choice is "accept for none" or "accept for all". Accept for all is not practical for an application with many operations.

Using ClassGraphDepthMax should be enough for most use cases.

ClassGraphDepthMax is largely independent of class cycles.