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

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