View mode: basic / threaded / horizontal-split · Log in · Help
November 27, 2006
Why are properties of concrete types not assignable?
I was trying to compose a complex number today and was reminded that 
this does not work:

    creal c;
    c.re = 1.0;
    c.im = 2.0;

Why is this?  I can't imagine it's a technical limitation, and I can 
think of a few instances where this is actually a useful feature 
(conversion from a string, for example), but there must be some reason 
for the current behavior.

The same goes for the array ptr property, though its behavior seems 
somewhat more understandable:

    char[] buf;
    buf.ptr = null; // fails

I suppose that buf.ptr is just syntactic sugar for &buf[0], and it is 
not assignable so the length property is always accurate?  And the .len 
struct member is not exposed to avoid confusing with .length?  This 
seems reasonable, though I've encountered a few instances where I wanted 
to manually manipulate these properties to avoid the risk of 
reallocation and wished they were assignable.  But slicing is powerful 
enough that direct member manipulation really isn't necessary, so 
perhaps it's safer to keep things the way they are for arrays.


Sean
November 27, 2006
Re: Why are properties of concrete types not assignable?
Sean Kelly wrote:
> I was trying to compose a complex number today and was reminded that 
> this does not work:
> 
>     creal c;
>     c.re = 1.0;
>     c.im = 2.0;
> 
> Why is this?  I can't imagine it's a technical limitation, and I can 
> think of a few instances where this is actually a useful feature 
> (conversion from a string, for example), but there must be some reason 
> for the current behavior.
> 
> The same goes for the array ptr property, though its behavior seems 
> somewhat more understandable:
> 
>     char[] buf;
>     buf.ptr = null; // fails
> 
> I suppose that buf.ptr is just syntactic sugar for &buf[0], and it is 
> not assignable so the length property is always accurate?  And the .len 
> struct member is not exposed to avoid confusing with .length?  This 
> seems reasonable, though I've encountered a few instances where I wanted 
> to manually manipulate these properties to avoid the risk of 
> reallocation and wished they were assignable.  But slicing is powerful 
> enough that direct member manipulation really isn't necessary, so 
> perhaps it's safer to keep things the way they are for arrays.
> 
> 
> Sean

I agree that .re and .im should probably be assignable. It's virtually 
impossible to break something like that, and I think that realistically 
you'll always get the value you want.

However, I don't agree that properties of dynamic arrays should be 
assignable. In my opinion, if you want to hack around at them, you 
should have to actually hack around at them:

union charray {
    char[] darr;
    struct {
        void *ptr;
        int len;
    }
}


That was at least it's very clear that you're doing something nasty, not 
something you could "accidentally" fall into.

Just my 2ยข

 - Gregor Richards
Top | Discussion index | About this forum | D home