Open chwarr opened 7 years ago
I imagine this issue was created in response to #428. Is the position being taken is that bonded<T>
really shouldn't work on "primitive" Bond types like int
, String
, vector<Y>
(for all Y
)? Is this out of design principle, or because it appears to be too hard/time consuming to fix?
Since it seems pretty reasonable that people might want to have bonded<vector<T>>
or generally just have a generic bonded<T>
(e.g. just passing through generic data, or for use in an inheritance like scheme) perhaps one of the following solutions would seem acceptable:
bonded<T>
to work on "primitive" Bond types (seems like probably the most straightforward)bonded<T>
Bond can just have a generic wrapper class that developers are supposed to know to use on string
, int
, vector<T>
, etc.Answer 3 is basically what we have now, but if this is the "supported" solution then maybe there should be a standard wrapper. I believe answer 1 is the most work out of the three but still significantly less work than what would be required to fully implement the behavior you have described above.
In short, why not just make bonded<T>
work on primitive types?
Yes, this was opened during my writing of a reply to #428. :-) The "meat" of the issue is over there: this is a bug fix to make today's Bond easier to use. If anyone is interested in discussion about what it would mean to serialize a non-struct type, head on over to #428.
The following .bond file does not fail during code generation. It ends up creating, in
Invalid_UsesString
, a field of typebonded<string>
, which technically is not permitted. The generated C++ code will fail to compile, and the generated C# code will throw an exception during creation of the Serializer.The current expectation is that for
bonded<T>
, theT
is a struct itself.In this particular case, the compiler can see all of the definitions and should be able to fail this. More complicated cases involving imports and forward declarations also need to be considered.
Bonus points for generating code in each of the languages that would prevent in-language instantiation of a generic struct with a non-struct type.