On Tuesday, 3 September 2013 at 00:05:04 UTC, Walter Bright wrote:
> On 9/2/2013 4:57 PM, Dylan Knutson wrote:
>> Can someone shed some light on this?
>
> It comes from C. This was done in C so that addresses of struct instances will always be unique.

So, because backwards compatibility is an important consideration, what type of code breakage might one expect if D was to implement zero-size structs?

On 9/2/2013 5:34 PM, Vladimir Panteleev wrote:
> On Tuesday, 3 September 2013 at 00:05:04 UTC, Walter Bright wrote:
>> On 9/2/2013 4:57 PM, Dylan Knutson wrote:
>>> Can someone shed some light on this?
>>
>> It comes from C. This was done in C so that addresses of struct instances will
>> always be unique.
>
> Why is that important, and why does D need it?
>
> In C, this might make some sense, however empty structs are much more useful in
> D, e.g. for metaprogramming.

There were huge debates about this back when the C standard was in development. I don't really want to start that up again :-), I don't remember all the pros and cons, suffice to say that with D's vaunted C compatibility I think it should behave the same way.

On Tuesday, 3 September 2013 at 04:25:33 UTC, Vladimir Panteleev wrote:
> On Tuesday, 3 September 2013 at 03:57:09 UTC, growler wrote:
>> If I see code like this I expect a & b to have different addresses.
>
> Why? What do you need that assumption for? What will break if the structs became 0-sized?

There's no real reason, it's just a personal preference. As I said I'm heavily influenced by a C/C++ background and as such would prefer a different syntax.

On Tuesday, 3 September 2013 at 04:33:16 UTC, Walter Bright wrote:
> There were huge debates about this back when the C standard was in development. I don't really want to start that up again :-), I don't remember all the pros and cons, suffice to say that with D's vaunted C compatibility I think it should behave the same way.

Fair enough. Was there any discussion on these forums about it? It sounds like an interesting topic of discussion, because I'm curious what the use cases are in D.

Not to start a debate on it, but what compatibility with C is D is afforded by not having zero sized structs? It seems like D has abandoned a fair number of C warts, so it seems odd that this (to me, obscure one) one would stay.

On 9/2/2013 9:39 PM, Dylan Knutson wrote:
> On Tuesday, 3 September 2013 at 04:33:16 UTC, Walter Bright wrote:
>> There were huge debates about this back when the C standard was in
>> development. I don't really want to start that up again :-), I don't remember
>> all the pros and cons, suffice to say that with D's vaunted C compatibility I
>> think it should behave the same way.
>
> Fair enough. Was there any discussion on these forums about it? It sounds like
> an interesting topic of discussion, because I'm curious what the use cases are
> in D.
>
> Not to start a debate on it, but what compatibility with C is D is afforded by
> not having zero sized structs? It seems like D has abandoned a fair number of C
> warts, so it seems odd that this (to me, obscure one) one would stay.

Not following this aspect of C would result in silent and unexpected changes in behavior when interfacing D to C data structures, which D is supposed to be very good at.

On Tuesday, 3 September 2013 at 05:51:36 UTC, Walter Bright wrote:
> Not following this aspect of C would result in silent and unexpected changes in behavior when interfacing D to C data structures, which D is supposed to be very good at.

Fair enough. I'll guess stick with `SomeStruct.tupleof.length == 0` to determine if a struct has no members.

On 03.09.2013 07:51, Walter Bright wrote:
> On 9/2/2013 9:39 PM, Dylan Knutson wrote:
>> On Tuesday, 3 September 2013 at 04:33:16 UTC, Walter Bright wrote:
>>> There were huge debates about this back when the C standard was in
>>> development. I don't really want to start that up again :-), I don't
>>> remember
>>> all the pros and cons, suffice to say that with D's vaunted C
>>> compatibility I
>>> think it should behave the same way.
>>
>> Fair enough. Was there any discussion on these forums about it? It
>> sounds like
>> an interesting topic of discussion, because I'm curious what the use
>> cases are
>> in D.
>>
>> Not to start a debate on it, but what compatibility with C is D is
>> afforded by
>> not having zero sized structs? It seems like D has abandoned a fair
>> number of C
>> warts, so it seems odd that this (to me, obscure one) one would stay.
>
> Not following this aspect of C would result in silent and unexpected
> changes in behavior when interfacing D to C data structures, which D is
> supposed to be very good at.

How about specifying extern(C) before each C structure? The majority of bindings already have "extern(C):" on top of module.

On 9/3/2013 9:00 AM, Piotr Szturmaj wrote:
> How about specifying extern(C) before each C structure? The majority of bindings
> already have "extern(C):" on top of module.

While we could do that, at what point does this become arcane complexity?

On 9/2/2013 9:28 PM, Dylan Knutson wrote:
> On Tuesday, 3 September 2013 at 00:05:04 UTC, Walter Bright wrote:
>> On 9/2/2013 4:57 PM, Dylan Knutson wrote:
>>> Can someone shed some light on this?
>>
>> It comes from C. This was done in C so that addresses of struct instances will
>> always be unique.
>
> So, because backwards compatibility is an important consideration, what type of
> code breakage might one expect if D was to implement zero-size structs?

Some background:

http://stackoverflow.com/questions/7881487/zero-sized-struct
http://stackoverflow.com/questions/10971651/zero-size-struct
http://stackoverflow.com/questions/755305/empty-structure-in-c
http://connect.microsoft.com/VisualStudio/feedback/details/355187/marshal-sizeof-returns-wrong-struct-size-for-empty-struct
https://mail.elegosoft.com/pipermail/m3devel/2012-October/010196.html

On Tuesday, 3 September 2013 at 19:30:53 UTC, Walter Bright wrote:
> On 9/3/2013 9:00 AM, Piotr Szturmaj wrote:
>> How about specifying extern(C) before each C structure? The majority of bindings
>> already have "extern(C):" on top of module.
>
> While we could do that, at what point does this become arcane complexity?

I think it depends how much metaprogramming could benefit in the language. Algebraic datatypes use zero sized structs in may places (see Rust, with Option(T) variants None and Some(T)), and I've heard of devs using structs as namespaces. In C, there was pretty much no metaprogramming to speak of, so semantic struct sizes just weren't a bit deal (as far as I can tell, that is).

But, in D, metaprogramming is a ubiquitous feature, so I do think it's reasonable to consider some way of specifying zero sized structs in the language. I'd argue for it to be an opt-in feature though, so empty structs, by default, can't have a zero size. This keeps code backwards compatible.

Perhaps something like `enum struct Foo;`, to indicate that it's just a compile-time used distinct type, and not a value? Just throwing that out there. I'm sure there is a better way to indicate that a type is just used as a type/namespace, without a value persay.

When you say retain C compatibility, do you mean having C code which makes use of empty structs still be compile-able with the D compiler? Or D code inter-oping with external C libraries?