You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DataConstRef is rather tricky because of its weird Python-style sometimes-value-sometimes-reference semantics, which don't integrate well with the concept of constness. This is causing trouble when we use it internally, and we're probably better off just using Data everywhere internally so we don't need weird hacks in mocks and tests. All this of course while we await that magical time when we figure out how to cleanly integrate sometimes-value-sometimes-reference semantics with constness and make it all perfect.
The text was updated successfully, but these errors were encountered:
Actually, it seems like a DataConstPtr would be better. This would be derived from DataConstRef, and add copy-assignment and move-assignment operators. That would make it compatible with standard containers, and would still keep the referred-to data from being modified. We could also safely add conversions from DataConstRef to DataConstPtr and back (back is automatic if DCP derives from DCR).
The only place where DataConstPtr wouldn't be able to replace DataConstRef is as the return value of DCR::operator[] or DCP::operator[], because that would break constness. So that will remain DataConstRef.
DataConstRef
is rather tricky because of its weird Python-style sometimes-value-sometimes-reference semantics, which don't integrate well with the concept of constness. This is causing trouble when we use it internally, and we're probably better off just usingData
everywhere internally so we don't need weird hacks in mocks and tests. All this of course while we await that magical time when we figure out how to cleanly integrate sometimes-value-sometimes-reference semantics with constness and make it all perfect.The text was updated successfully, but these errors were encountered: