Read-only property without @property

[H. S. Teoh via Digitalmars-d]

On Sat, Sep 27, 2014 at 12:43:19AM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 9/26/14 9:26 PM, H. S. Teoh via Digitalmars-d wrote:
> 
> >Not a bad start. Though I do note that *declaring* an unsafe union
> >(according to the above definitions) is currently allowed in @safe
> >code by the compiler, but attempts to access a union member that
> >overlaps with a pointer is rejected.
> 
> It makes sense that you can declare unsafe unions, because a
> declaration itself isn't @safe, it's only code that is.
> 
> But my attempts to test this haven't yielded an error.
> 
> e.g.:
> 
> class Foo
> {
>     union {
>         private int _a;
>         public int *a;
>     }
> 
>     void setA(int x) @safe { *a = x;}
> }
> 
> no complaints...

Argh, looks like another incompletely-implemented part of the compiler:

	void fun() @safe {
		union U {
			int  p;
			int* q;
		}
		U u;
		u.p++;		// compiles
		u.q = null;	// compiles
		*u.q++;		// x.d(9): Error: field U.q cannot be accessed in @safe code because it overlaps with a pointer
	}

While it sorta makes sense in its own way that it's OK to mess around
with the union as long as you don't actually try to dereference an
overlapped pointer, the error message inspires no confidence that this
was actually intentional. :-( On the contrary, it sounds like u.p++ and
u.q = null was supposed to be rejected as well, but for some reason
aren't.


> >IOW, the compiler doesn't refuse definitions of potentially unsafe
> >unions, as long as you don't actually try to do something unsafe with
> >them. That might make unions more useful (they can be passed around
> >in @safe code as long as certain operations are avoided), but
> >probably also trickier to implement correctly.
> 
> I think it *should* be that way, but I'm not convinced it is yet.
[...]

Apparently I hit jackpot in attempting to try dereferencing an
overlapped pointer first. All the other cases seem to be unimplemented!

I can't decide whether or not this should be filed as a bug or an
enhancement request, because currently we have the paradoxical situation
where @safe code isn't actually allowed to *dereference* an overlapped
pointer, but it *can* stomp all over the pointer by writing garbage to
overlapping fields so that @system callers can totally screw themselves
over when they dereference it!


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce