struct point { int x, y; }
point p2 = { 1,2 };

I am getting this while compilation:
".\geometry.d(43): variable rect.this.p2 is not a static and cannot have
static initializer"

Is there any logical / physical problems for "only statics" limitations? As far as I can see from grammar point of view such initializers are not so far from "static point p2 = { 1,2 };"

As structs have no ctors then I think having something like

point p2 = { x:1, y:2 };

would be extremely nice.

Andrew Fedoniouk.
http://terrainformatica.com

> As structs have no ctors then I think having something like
>
> point p2 = { x:1, y:2 };
>
> would be extremely nice.

I totally agree.  That fits in nicely with the existing syntax, and sometimes it's just a pain to have to make a static opcall (fake ctor) for each struct.

I am using  something like this for while:

point p = point.make(1,2);

ugly but works.

struct point
{
  int x,y;

  // external ctor (structs do not have ctors in D)
  // use it as:  point p = point.make(1,2);
  static point  make( int x, int y ) { point p; p.x = x; p.y = y; return
p; }
}

Andrew.


"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d089jo$2ndp$1@digitaldaemon.com...
>> As structs have no ctors then I think having something like
>>
>> point p2 = { x:1, y:2 };
>>
>> would be extremely nice.
>
> I totally agree.  That fits in nicely with the existing syntax, and sometimes it's just a pain to have to make a static opcall (fake ctor) for each struct.
> 

In article <d08fu6$2t06$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>I am using  something like this for while:
>
>point p = point.make(1,2);
>
>ugly but works.
>
>struct point
>{
>  int x,y;
>
>  // external ctor (structs do not have ctors in D)
>  // use it as:  point p = point.make(1,2);
>  static point  make( int x, int y ) { point p; p.x = x; p.y = y; return
>p; }
>}
>
>Andrew.
>
>
>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d089jo$2ndp$1@digitaldaemon.com...
>>> As structs have no ctors then I think having something like
>>>
>>> point p2 = { x:1, y:2 };
>>>
>>> would be extremely nice.
>>
>> I totally agree.  That fits in nicely with the existing syntax, and sometimes it's just a pain to have to make a static opcall (fake ctor) for each struct.
>> 
>

The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It also works when you have arrays of points "point[] p3 = [{x:1,y:2},{x:3,y:4}];". I think it came up a while ago - or comes up every now and then, to have some kind of non-static versions of both of these.

I've personally stopped using the static opCall. Instead nowadays I use toplevel functions called things like toPoint or depending on the struct I use some custom name like LTRB or LTWH for constructing rectangles from left,top,right,bottom or left,top,width,height respectively. The rectangle thing I started in MinWin because I can never remember which system stores their rectangles in which style so I let you do either and have the code self-document which you are doing. These conventions will probably evolve for a while.

> The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It
> also
> works when you have arrays of points "point[] p3 =
> [{x:1,y:2},{x:3,y:4}];". I
> think it came up a while ago - or comes up every now and then, to have
> some kind
> of non-static versions of both of these.
>

Yep. Shall we ask Walter to do something?
I've digged in compiler source, seems like this is doable pretty easily.

> I've personally stopped using the static opCall. Instead nowadays I use
> toplevel
> functions called things like toPoint or depending on the struct I use some
> custom name like LTRB or LTWH for constructing rectangles from
> left,top,right,bottom or left,top,width,height respectively. The rectangle
> thing
> I started in MinWin because I can never remember which system stores their
> rectangles in which style so I let you do either and have the code
> self-document
> which you are doing. These conventions will probably evolve for a while.

Ben, what is your opinion about using platform dependent Rect implementation
on
this stage?
I've decided to use one "standard" implementation for that.
J-SMILE uses  16 "native" graphic functions from underlying OS
so I think it is not a big deal to convert Rect, Point, etc in native
function wrapers in place. Huh?

Andrew.

In article <d08vbq$a70$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>> The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It
>> also
>> works when you have arrays of points "point[] p3 =
>> [{x:1,y:2},{x:3,y:4}];". I
>> think it came up a while ago - or comes up every now and then, to have
>> some kind
>> of non-static versions of both of these.
>>
>
>Yep. Shall we ask Walter to do something?
>I've digged in compiler source, seems like this is doable pretty easily.

I think he knows but requesting again wouldn't hurt, I guess.

>> I've personally stopped using the static opCall. Instead nowadays I use
>> toplevel
>> functions called things like toPoint or depending on the struct I use some
>> custom name like LTRB or LTWH for constructing rectangles from
>> left,top,right,bottom or left,top,width,height respectively. The rectangle
>> thing
>> I started in MinWin because I can never remember which system stores their
>> rectangles in which style so I let you do either and have the code
>> self-document
>> which you are doing. These conventions will probably evolve for a while.
>
>Ben, what is your opinion about using platform dependent Rect implementation
>on this stage?
>I've decided to use one "standard" implementation for that.
>J-SMILE uses  16 "native" graphic functions from underlying OS
>so I think it is not a big deal to convert Rect, Point, etc in native
>function wrapers in place. Huh?

Either way is reasonable but for MinWin I chose to wrap all native types where possible since a goal of MinWin is to make it easy to do platform-specific coding. For a while I was actually just using aliases for Rect to be RECT or XRectangle etc but a few days ago I decided that style wasn't as convenient as defining new types that wrap the native type. For Rect and Point it might not matter but for event structs and font structs the fancy parts differ quite a bit between platform.

>
>Andrew.