On Sunday, April 01, 2018 10:31:46 Andrei Alexandrescu via Digitalmars-d wrote: > On 4/1/18 9:37 AM, Jonathan M Davis wrote: > > One issue is that postblit constructors fundamentally don't work with > > const. > Actually they do...
How so? In the postblit, you're dealing with a copy of an object where everything is already initialized. Mutating the object would violate const. It could be made to work for primitive types that the compiler understands and knows that the member variable is truly independent - e.g. it could be allowed to mutate an int, or it could be allowed to mutate a pointer while treating what it points to as const, but as soon as you're dealing with user-defined types, you're screwed - especially if you're dealing with something like a struct with a user-defined opAssign. You're reading an existing value and then mutating it, and it has to be at least tail-const, because the original was const - and tail-const is pretty meaningless for structs and can't really be represented in the type system for classes. So, I don't see how postblit could be made to work with a const object of any real complexity. It can be made to work in some corner cases but not in general. Kenji worked on a solution to the problem with const and postblit several years ago (and I'm not sure how close he got to really solving it), but as I recall, you and Walter shot it down because it was overly complicated. How are you proposing that const work with postblit? - Jonathan M Davis
