• Arcane Jill (12/38) Aug 22 2004 Moving this here for general discussion, as I don't think it's a bug rep...
• Matthew (19/64) Aug 22 2004 interfacing
• Ben Hinkle (5/96) Aug 22 2004 To me the word "struct" suggests a certain semantics (eg, allocated on t...
• Regan Heath (5/113) Aug 22 2004 So lets call the D struct a 'memblock' or 'stackblock' or ..
• Tom Sawyer (12/56) Aug 22 2004 That doesn't accurately portray what the object is. Think of it this way...
• Regan Heath (7/71) Aug 22 2004 Correct me if I am wrong but A struct differs from a scope in that a
• Tom Sawyer (6/22) Aug 23 2004 They are different internally, but look much the same from a programming
• Regan Heath (19/42) Aug 23 2004 They may look similar, but they differ in meaning.. a struct is a
• Arcane Jill (4/10) Aug 22 2004 Outside of a statment block, local variables declared within that block ...
• Tom Sawyer (4/15) Aug 23 2004 Static local variables always exist. I'm not sure if they are accessible

Arcane Jill <Arcane_member pathlink.com> writes:

Moving this here for general discussion, as I don't think it's a bug report any
more.

In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9g21$22i$1 digitaldaemon.com...
 In article <cg8bhk$2ctl$1 digitaldaemon.com>, Matthew says...

Which takes me back to my earlier point that bit should be banned from structs
and unions.

 I don't like the idea that we would be /forbidden/ from using bits in structs,
 just in case we might want to pass that struct to a C function, or port the
code
 to C, or whatever. What if we /don't/ want to do any of those things?

 Should we also forbid complex numbers in structs? Or classes? Or associative
 arrays? Or, indeed, /anything/ that D has which C doesn't?

Of course. (& don't forget unions as well)

And if that brings out a howl of protest, then I suggest that we need another
aggregate class-key for what we now know
as struct, since clearly we need something that is unambiguously useful and
free of evil subtle pitfalls for interfacing
with C. That is, after all, supposedly one of D's major plusses over other C++
evolutions!



You might counter that we are able to include non-POD types in structs in C++.
There are several responses:P

1. C++ does not have an ABI. Kind of a strange argument, I grant you, but
basically without an ABI there's an "excuse"
for allowing this inconsistency.
2. C++ has a pre-processor, such that one can conditionally define C++ aspects
of a struct (e.g. static members, ctors,
etc.), without upsetting the equivalence of size from one language to the other.
3. <stealing myself against the inevitable abuse> C++ practitioners are going
to be more able to handle issues of
complexity.
4. So what? D doesn't take on other mistakes in C++'s design.
5. C++ has a shared inclusion model, and shares fundamental types and their
sizes, between C and C++. My "heat" on this
issue is primarily driven by the fact that identical looking structs in C and D
can have radically different structures
(and this is *not* simply an issue of packing).


What about an extra keyword like "strict" or something, which disallows anything
which is not a POD? I confess I don't like the idea of completely disallowing
non-PODs in all structs. A while back, some folk were suggesting that I
implement my class Int as a struct, because it had copy semantics. There were
reasons why I didn't do that, but, if I had, that struct would have been
disallowed under your last suggestion. On the other hand, a struct specially
marked as a POD would presumably keep you happy as well as I? Besides, "strict
struct" sounds kinda poetic.

Arcane Jill

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9p04$9p6$1 digitaldaemon.com...
 Moving this here for general discussion, as I don't think it's a bug report any
 more.

 In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9g21$22i$1 digitaldaemon.com...
 In article <cg8bhk$2ctl$1 digitaldaemon.com>, Matthew says...

Which takes me back to my earlier point that bit should be banned from structs
and unions.

 I don't like the idea that we would be /forbidden/ from using bits in structs,
 just in case we might want to pass that struct to a C function, or port the
code
 to C, or whatever. What if we /don't/ want to do any of those things?

 Should we also forbid complex numbers in structs? Or classes? Or associative
 arrays? Or, indeed, /anything/ that D has which C doesn't?

Of course. (& don't forget unions as well)

And if that brings out a howl of protest, then I suggest that we need another
aggregate class-key for what we now


know
as struct, since clearly we need something that is unambiguously useful and
free of evil subtle pitfalls for


interfacing
with C. That is, after all, supposedly one of D's major plusses over other C++
evolutions!



You might counter that we are able to include non-POD types in structs in C++.
There are several responses:P

1. C++ does not have an ABI. Kind of a strange argument, I grant you, but
basically without an ABI there's an


"excuse"
for allowing this inconsistency.
2. C++ has a pre-processor, such that one can conditionally define C++ aspects
of a struct (e.g. static members,


ctors,
etc.), without upsetting the equivalence of size from one language to the other.
3. <stealing myself against the inevitable abuse> C++ practitioners are going
to be more able to handle issues of
complexity.
4. So what? D doesn't take on other mistakes in C++'s design.
5. C++ has a shared inclusion model, and shares fundamental types and their
sizes, between C and C++. My "heat" on


this
issue is primarily driven by the fact that identical looking structs in C and D
can have radically different


structures
(and this is *not* simply an issue of packing).


 What about an extra keyword like "strict" or something, which disallows
anything
 which is not a POD? I confess I don't like the idea of completely disallowing
 non-PODs in all structs. A while back, some folk were suggesting that I
 implement my class Int as a struct, because it had copy semantics. There were
 reasons why I didn't do that, but, if I had, that struct would have been
 disallowed under your last suggestion. On the other hand, a struct specially
 marked as a POD would presumably keep you happy as well as I? Besides, "strict
 struct" sounds kinda poetic.

Nope, too easy to abuse. The smart answer is to think of another class key for
what we call struct.

We have the following types of things:

- unions
- C-compatible structs
- "D" structs
- classes

To my mind, mixing "D" structs and C-compatible structs has always been a very
odd idea, and, in light of what we've
realised about bit members/bitfields over the last couple of days, I now
consider it completely broken.

"D" structs are a weird thing to call struct, and we should leave struct to
what the rest of the world knows it as. I'm
sure one of the myriad geniuses who opine on this group can think of a new
class-key for that type of thing. "valclass",
"vclass", "val" all such hard, but might inspire some creative soul.

Otherwise, we'll just have utter confusion, and well-deserved criticism.

Ben Hinkle <bhinkle4 juno.com> writes:

Matthew wrote:

 
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cg9p04$9p6$1 digitaldaemon.com...
 Moving this here for general discussion, as I don't think it's a bug
 report any more.

 In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9g21$22i$1 digitaldaemon.com...
 In article <cg8bhk$2ctl$1 digitaldaemon.com>, Matthew says...

Which takes me back to my earlier point that bit should be banned
from structs and unions.

 I don't like the idea that we would be /forbidden/ from using bits in
 structs, just in case we might want to pass that struct to a C
 function, or port the code to C, or whatever. What if we /don't/ want
 to do any of those things?

 Should we also forbid complex numbers in structs? Or classes? Or
 associative arrays? Or, indeed, /anything/ that D has which C doesn't?

Of course. (& don't forget unions as well)

And if that brings out a howl of protest, then I suggest that we need
another aggregate class-key for what we now


 know
as struct, since clearly we need something that is unambiguously useful
and free of evil subtle pitfalls for


 interfacing
with C. That is, after all, supposedly one of D's major plusses over
other C++ evolutions!



You might counter that we are able to include non-POD types in structs
in C++. There are several responses:P

1. C++ does not have an ABI. Kind of a strange argument, I grant you,
but basically without an ABI there's an


 "excuse"
for allowing this inconsistency.
2. C++ has a pre-processor, such that one can conditionally define C++
aspects of a struct (e.g. static members,


 ctors,
etc.), without upsetting the equivalence of size from one language to
the other. 3. <stealing myself against the inevitable abuse> C++
practitioners are going to be more able to handle issues of complexity.
4. So what? D doesn't take on other mistakes in C++'s design.
5. C++ has a shared inclusion model, and shares fundamental types and
their sizes, between C and C++. My "heat" on


 this
issue is primarily driven by the fact that identical looking structs in
C and D can have radically different


 structures
(and this is *not* simply an issue of packing).


 What about an extra keyword like "strict" or something, which disallows
 anything which is not a POD? I confess I don't like the idea of
 completely disallowing non-PODs in all structs. A while back, some folk
 were suggesting that I implement my class Int as a struct, because it had
 copy semantics. There were reasons why I didn't do that, but, if I had,
 that struct would have been disallowed under your last suggestion. On the
 other hand, a struct specially marked as a POD would presumably keep you
 happy as well as I? Besides, "strict struct" sounds kinda poetic.

 
 Nope, too easy to abuse. The smart answer is to think of another class key
 for what we call struct.
 
 We have the following types of things:
 
 - unions
 - C-compatible structs
 - "D" structs
 - classes
 
 To my mind, mixing "D" structs and C-compatible structs has always been a
 very odd idea, and, in light of what we've realised about bit
 members/bitfields over the last couple of days, I now consider it
 completely broken.
 
 "D" structs are a weird thing to call struct, and we should leave struct
 to what the rest of the world knows it as. I'm sure one of the myriad
 geniuses who opine on this group can think of a new class-key for that
 type of thing. "valclass", "vclass", "val" all such hard, but might
 inspire some creative soul.
 
 Otherwise, we'll just have utter confusion, and well-deserved criticism.

To me the word "struct" suggests a certain semantics (eg, allocated on the

structure with these semantics. C compatibility is orthogonal, much like
the size of "int" or "char[]".

Regan Heath <regan netwin.co.nz> writes:

On Sun, 22 Aug 2004 08:40:18 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Matthew wrote:

 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cg9p04$9p6$1 digitaldaemon.com...
 Moving this here for general discussion, as I don't think it's a bug
 report any more.

 In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9g21$22i$1 digitaldaemon.com...
 In article <cg8bhk$2ctl$1 digitaldaemon.com>, Matthew says...

Which takes me back to my earlier point that bit should be banned
from structs and unions.

 I don't like the idea that we would be /forbidden/ from using bits 


 in
 structs, just in case we might want to pass that struct to a C
 function, or port the code to C, or whatever. What if we /don't/ 


 want
 to do any of those things?

 Should we also forbid complex numbers in structs? Or classes? Or
 associative arrays? Or, indeed, /anything/ that D has which C 


 doesn't?
Of course. (& don't forget unions as well)

And if that brings out a howl of protest, then I suggest that we need
another aggregate class-key for what we now


 know
as struct, since clearly we need something that is unambiguously 

 useful
and free of evil subtle pitfalls for


 interfacing
with C. That is, after all, supposedly one of D's major plusses over
other C++ evolutions!



You might counter that we are able to include non-POD types in structs
in C++. There are several responses:P

1. C++ does not have an ABI. Kind of a strange argument, I grant you,
but basically without an ABI there's an


 "excuse"
for allowing this inconsistency.
2. C++ has a pre-processor, such that one can conditionally define C++
aspects of a struct (e.g. static members,


 ctors,
etc.), without upsetting the equivalence of size from one language to
the other. 3. <stealing myself against the inevitable abuse> C++
practitioners are going to be more able to handle issues of 

 complexity.
4. So what? D doesn't take on other mistakes in C++'s design.
5. C++ has a shared inclusion model, and shares fundamental types and
their sizes, between C and C++. My "heat" on


 this
issue is primarily driven by the fact that identical looking structs 

 in
C and D can have radically different


 structures
(and this is *not* simply an issue of packing).


 What about an extra keyword like "strict" or something, which disallows
 anything which is not a POD? I confess I don't like the idea of
 completely disallowing non-PODs in all structs. A while back, some folk
 were suggesting that I implement my class Int as a struct, because it 
 had
 copy semantics. There were reasons why I didn't do that, but, if I had,
 that struct would have been disallowed under your last suggestion. On 
 the
 other hand, a struct specially marked as a POD would presumably keep 
 you
 happy as well as I? Besides, "strict struct" sounds kinda poetic.

 Nope, too easy to abuse. The smart answer is to think of another class 
 key
 for what we call struct.

 We have the following types of things:

 - unions
 - C-compatible structs
 - "D" structs
 - classes

 To my mind, mixing "D" structs and C-compatible structs has always been 
 a
 very odd idea, and, in light of what we've realised about bit
 members/bitfields over the last couple of days, I now consider it
 completely broken.

 "D" structs are a weird thing to call struct, and we should leave struct
 to what the rest of the world knows it as. I'm sure one of the myriad
 geniuses who opine on this group can think of a new class-key for that
 type of thing. "valclass", "vclass", "val" all such hard, but might
 inspire some creative soul.

 Otherwise, we'll just have utter confusion, and well-deserved criticism.

 To me the word "struct" suggests a certain semantics (eg, allocated on 
 the

 structure with these semantics. C compatibility is orthogonal, much like
 the size of "int" or "char[]".

So lets call the D struct a 'memblock' or 'stackblock' or ..

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Tom Sawyer <tsawyer hannible.mo> writes:

On Mon, 23 Aug 2004 10:24:04 +1200, Regan Heath wrote:

 What about an extra keyword like "strict" or something, which disallows
 anything which is not a POD? I confess I don't like the idea of
 completely disallowing non-PODs in all structs. A while back, some folk
 were suggesting that I implement my class Int as a struct, because it 
 had
 copy semantics. There were reasons why I didn't do that, but, if I had,
 that struct would have been disallowed under your last suggestion. On 
 the
 other hand, a struct specially marked as a POD would presumably keep 
 you
 happy as well as I? Besides, "strict struct" sounds kinda poetic.

 Nope, too easy to abuse. The smart answer is to think of another class 
 key
 for what we call struct.

 We have the following types of things:

 - unions
 - C-compatible structs
 - "D" structs
 - classes

 To my mind, mixing "D" structs and C-compatible structs has always been 
 a
 very odd idea, and, in light of what we've realised about bit
 members/bitfields over the last couple of days, I now consider it
 completely broken.

 "D" structs are a weird thing to call struct, and we should leave struct
 to what the rest of the world knows it as. I'm sure one of the myriad
 geniuses who opine on this group can think of a new class-key for that
 type of thing. "valclass", "vclass", "val" all such hard, but might
 inspire some creative soul.

 Otherwise, we'll just have utter confusion, and well-deserved criticism.

 To me the word "struct" suggests a certain semantics (eg, allocated on 
 the

 structure with these semantics. C compatibility is orthogonal, much like
 the size of "int" or "char[]".

 
 So lets call the D struct a 'memblock' or 'stackblock' or ..

That doesn't accurately portray what the object is. Think of it this way -
we implicitly have structures of any combination of objects we wish
already. This is just the range of variables defined at the start of a
block of statements or other places. Within the scope of the block, you
refer to the member by just using the member name. Outside the scope of
the block, you access the member by referring the the name of the block
plus the member name. This looks like a structure reference from a
programming point of view.

So why not make this official? Add a "scope" keyword that then takes
any combination of variables or what-not and makes it accessible in the
same manner.

Regan Heath <regan netwin.co.nz> writes:

On Sun, 22 Aug 2004 21:56:44 -0700, Tom Sawyer <tsawyer hannible.mo> wrote:
 On Mon, 23 Aug 2004 10:24:04 +1200, Regan Heath wrote:

 What about an extra keyword like "strict" or something, which 
 disallows
 anything which is not a POD? I confess I don't like the idea of
 completely disallowing non-PODs in all structs. A while back, some 
 folk
 were suggesting that I implement my class Int as a struct, because it
 had
 copy semantics. There were reasons why I didn't do that, but, if I 
 had,
 that struct would have been disallowed under your last suggestion. On
 the
 other hand, a struct specially marked as a POD would presumably keep
 you
 happy as well as I? Besides, "strict struct" sounds kinda poetic.

 Nope, too easy to abuse. The smart answer is to think of another class
 key
 for what we call struct.

 We have the following types of things:

 - unions
 - C-compatible structs
 - "D" structs
 - classes

 To my mind, mixing "D" structs and C-compatible structs has always 
 been
 a
 very odd idea, and, in light of what we've realised about bit
 members/bitfields over the last couple of days, I now consider it
 completely broken.

 "D" structs are a weird thing to call struct, and we should leave 
 struct
 to what the rest of the world knows it as. I'm sure one of the myriad
 geniuses who opine on this group can think of a new class-key for that
 type of thing. "valclass", "vclass", "val" all such hard, but might
 inspire some creative soul.

 Otherwise, we'll just have utter confusion, and well-deserved 
 criticism.

 To me the word "struct" suggests a certain semantics (eg, allocated on
 the

 structure with these semantics. C compatibility is orthogonal, much 
 like
 the size of "int" or "char[]".

 So lets call the D struct a 'memblock' or 'stackblock' or ..

 That doesn't accurately portray what the object is. Think of it this way 
 -
 we implicitly have structures of any combination of objects we wish
 already. This is just the range of variables defined at the start of a
 block of statements or other places. Within the scope of the block, you
 refer to the member by just using the member name. Outside the scope of
 the block, you access the member by referring the the name of the block
 plus the member name. This looks like a structure reference from a
 programming point of view.

 So why not make this official? Add a "scope" keyword that then takes
 any combination of variables or what-not and makes it accessible in the
 same manner.

Correct me if I am wrong but A struct differs from a scope in that a 
struct defines the ordering in memory of it's contained types, a scope 
doesn't.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Tom Sawyer <tsawyer hannible.mo> writes:

On Mon, 23 Aug 2004 17:05:01 +1200, Regan Heath wrote:

 On Sun, 22 Aug 2004 21:56:44 -0700, Tom Sawyer <tsawyer hannible.mo> wrote:

 we implicitly have structures of any combination of objects we wish
 already. This is just the range of variables defined at the start of a
 block of statements or other places. Within the scope of the block, you
 refer to the member by just using the member name. Outside the scope of
 the block, you access the member by referring the the name of the block
 plus the member name. This looks like a structure reference from a
 programming point of view.

 So why not make this official? Add a "scope" keyword that then takes
 any combination of variables or what-not and makes it accessible in the
 same manner.

 
 Correct me if I am wrong but A struct differs from a scope in that a 
 struct defines the ordering in memory of it's contained types, a scope 
 doesn't.

They are different internally, but look much the same from a programming
point of view. I was wondering if it wouldn't be too difficult to extend
the "looks like" into an actual structural feature.

It also doesn't need to be called "scope," that was just a suggestion. It
could be called any number of things like "aggregate" or "compound".

Regan Heath <regan netwin.co.nz> writes:

On Mon, 23 Aug 2004 14:35:46 -0700, Tom Sawyer <tsawyer hannible.mo> wrote:
 On Mon, 23 Aug 2004 17:05:01 +1200, Regan Heath wrote:

 On Sun, 22 Aug 2004 21:56:44 -0700, Tom Sawyer <tsawyer hannible.mo> 
 wrote:

 we implicitly have structures of any combination of objects we wish
 already. This is just the range of variables defined at the start of a
 block of statements or other places. Within the scope of the block, you
 refer to the member by just using the member name. Outside the scope of
 the block, you access the member by referring the the name of the block
 plus the member name. This looks like a structure reference from a
 programming point of view.

 So why not make this official? Add a "scope" keyword that then takes
 any combination of variables or what-not and makes it accessible in the
 same manner.

 Correct me if I am wrong but A struct differs from a scope in that a
 struct defines the ordering in memory of it's contained types, a scope
 doesn't.

 They are different internally, but look much the same from a programming
 point of view. I was wondering if it wouldn't be too difficult to extend
 the "looks like" into an actual structural feature.

They may look similar, but they differ in meaning.. a struct is a 
declaration of something that might exist at a later time, a scope exists 
when you see it, i.e.

struct a {
   int a;
}

means 0 or more of these might exist some time later.

if (true) {
   int a;
}

means 1 of these exists now (possible more than 1 if the code is threaded).

In addition a scope contains inline code, and is created upon entry and 
destroyed on exit.

 It also doesn't need to be called "scope," that was just a suggestion. It
 could be called any number of things like "aggregate" or "compound".

Those names are better. I don't think we should confuse 'struct' with 
'scope' I think they're different concepts.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Arcane Jill <Arcane_member pathlink.com> writes:

In article <pan.2004.08.23.04.56.43.448847 hannible.mo>, Tom Sawyer says...

we implicitly have structures of any combination of objects we wish
already. This is just the range of variables defined at the start of a
block of statements or other places. Within the scope of the block, you
refer to the member by just using the member name. Outside the scope of
the block, you access the member by referring the the name of the block
plus the member name.

Outside of a statment block, local variables declared within that block /don't
exist/. They cannot be reference in any way. Am I missing something?

Arcane Jill

Tom Sawyer <tsawyer hannible.mo> writes:

On Mon, 23 Aug 2004 05:56:13 +0000, Arcane Jill wrote:

 In article <pan.2004.08.23.04.56.43.448847 hannible.mo>, Tom Sawyer says...
 
we implicitly have structures of any combination of objects we wish
already. This is just the range of variables defined at the start of a
block of statements or other places. Within the scope of the block, you
refer to the member by just using the member name. Outside the scope of
the block, you access the member by referring the the name of the block
plus the member name.

 
 Outside of a statment block, local variables declared within that block /don't
 exist/. They cannot be reference in any way. Am I missing something?

Static local variables always exist. I'm not sure if they are accessible
outside the function as I just recently started working with D, but the
certainly exist.