Postblit bug

[ketmar via Digitalmars-d]

On Fri, 17 Oct 2014 16:19:46 +0000
IgorStepanov via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Friday, 17 October 2014 at 15:20:50 UTC, ketmar via 
> Digitalmars-d wrote:
> > On Fri, 17 Oct 2014 14:41:36 +0000
> > IgorStepanov via Digitalmars-d <digitalmars-d at puremagic.com> 
> > wrote:
> >
> >> What happends if we will ignore const/immutable modifier for 
> >> postblits? Is it create any holes?
> > it will break "const promise". i.e. "const/immutable data is 
> > not really
> > immutable now, it can be modified".
> 
> It's just common words=)
> I meant that when postblit is called when new object is being 
> creating and doesn't exists for user code.
> E.g.
> const S v1 = v2;
> Ok, v1 _will_ be const when it will be _created_.
> However postblit can think that object is mutable, because it 
> called before the first accessing to the object from user code.
> Thus I ask about case when postblit may mutate a const object, 
> which created before postblitted object and may been accessed 
> from user code before this postblitting.
what if compiler knows 'v2' value at compile time? compiler can put
'v1' in read-only section, and then postblitter will try to mutate
'v1'... ah, segfault. yet postblitter can do some other things, like,
for example, registering 'v1' in some king of runtime storage, so it
can't be optimized away.

and then the programmer changes postblitter to mutate some fields. it
all compiles fine and segfaults.

const promises can't be dropped that easy. yes, the compiler doesn't do
such things *now*, but it's ok for it to do it later and... kaboom!
previously working code is not working anymore.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141017/38bc209e/attachment-0001.sig>