RazvanN <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #5 from RazvanN <> ---
(In reply to Steven Schveighoffer from comment #4)
> Posted it on the forums as well, but I'll do so here too:
> postblit is what is used to do things like reference counting. You may be
> altering data that isn't actually part of the struct, so we still do need a
> postblit capability for immutable structs.
> Basically the same thing that anonymous4 said, but with a real use case.
> (In reply to Jonathan M Davis from comment #3)
> > And it's impossible for an immutable or const postblit
> > constructor to be called in the first place. If you try and declare a const
> > or immutable postblit constructor, you just end up with compilation errors,
> > because they don't work - and they can't work, not for what the purpose of a
> > postblit constructor is.
> The purpose is to run some code after blitting. Which is perfectly
> reasonable for immutable and const structs as well.
> What we should do is make it possible for immutable/const postblit to work.
> i.e.
> immutable S s;
> immutable y = s; // Error: immutable method S.__postblit is not callable
> using a mutable object
> Why does it think y is mutable? This should work.

That's a different problem: the compiler creates a function __postblit which
represents the postblit; when it does that it checks for the struct declaration
qualifiers (in this case, none) and forwards them to the postblit. Later, when
the immutable instance is created, all members are considered immutable, except
for the postblit. That is also the case for shared : [1]



Reply via email to