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

"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.

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 stack, copy-by-value, etc). C# uses the word "struct" to declare a data structure with these semantics. C compatibility is orthogonal, much like the size of "int" or "char[]".

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
> stack, copy-by-value, etc). C# uses the word "struct" to declare a data
> 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/

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
>> stack, copy-by-value, etc). C# uses the word "struct" to declare a data
>> 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.

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
>>> stack, copy-by-value, etc). C# uses the word "struct" to declare a data
>>> 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/

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

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.

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".

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/