• Sean Kelly (22/22) Nov 27 2006 I was trying to compose a complex number today and was reminded that
• Gregor Richards (18/47) Nov 27 2006 I agree that .re and .im should probably be assignable. It's virtually

Sean Kelly <sean f4.ca> writes:

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

Gregor Richards <Richards codu.org> writes:

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