Now that we have struct literals, the old C-style struct initializers don't seem to be necessary.
The variations with named initializers are not really implemented -- the example in the spec doesn't work, and most uses of them cause compiler segfaults or wrong code generation. EG...

struct Move{
   int D;
}
enum Move genMove = { D:4 };
immutable Move b = genMove;

It's not difficult to fix these compiler problems, but I'm just not sure if it's worth implementing. Maybe they should just be dropped? (The { field: value } style anyway).

== Quote from Don (nospam@nospam.com)'s article
> Now that we have struct literals, the old C-style struct initializers
> don't seem to be necessary.
> The variations with named initializers are not really implemented -- the
> example in the spec doesn't work, and most uses of them cause compiler
> segfaults or wrong code generation. EG...
> struct Move{
>     int D;
> }
> enum Move genMove = { D:4 };
> immutable Move b = genMove;
> It's not difficult to fix these compiler problems, but I'm just not sure
> if it's worth implementing. Maybe they should just be dropped? (The {
> field: value } style anyway).

I'd be inclined to say go for it, because it's yet another crufty feature inherited from C that I don't use, was barely aware even existed, and has been superseded by a better feature that's unique to D.  What can be done with struct initializers that can't be done just as easily with struct literals?  As far as I can tell (correct me if I'm wrong), nothing.

IMHO we concern ourselves with C source compatibility and ease of porting C code too much sometimes.  If people want a language that's source compatible with C, they want C++ and they know where to find it.  If they want a language that sacrifices backwards compatibility to get rid of tons of cruft, then that's what D is and we shouldn't be ashamed of it.  If we kinda sorta care about C source compatibility, we won't attract either audience.

Don wrote:
> Now that we have struct literals, the old C-style struct initializers don't seem to be necessary.
> The variations with named initializers are not really implemented -- the example in the spec doesn't work, and most uses of them cause compiler segfaults or wrong code generation. EG...
> 
> struct Move{
>    int D;
> }
> enum Move genMove = { D:4 };
> immutable Move b = genMove;
> 
> It's not difficult to fix these compiler problems, but I'm just not sure if it's worth implementing. Maybe they should just be dropped? (The { field: value } style anyway).
> 
> 

Funny, I've been thinking the same thing. Those initializers are pretty much obsolete, the only thing left is the field name thing. To keep the field name thing with the newer struct literals would require named function parameters as well, something doable but I'm not ready to do all the work to implement that yet.

Or just drop the field name thing, as you suggest.

Walter Bright wrote:
> Don wrote:
>> Now that we have struct literals, the old C-style struct initializers don't seem to be necessary.
>> The variations with named initializers are not really implemented -- the example in the spec doesn't work, and most uses of them cause compiler segfaults or wrong code generation. EG...
>>
>> struct Move{
>>    int D;
>> }
>> enum Move genMove = { D:4 };
>> immutable Move b = genMove;
>>
>> It's not difficult to fix these compiler problems, but I'm just not sure if it's worth implementing. Maybe they should just be dropped? (The { field: value } style anyway).
>>
>>
> 
> Funny, I've been thinking the same thing. Those initializers are pretty much obsolete, the only thing left is the field name thing. To keep the field name thing with the newer struct literals would require named function parameters as well, something doable but I'm not ready to do all the work to implement that yet.
> 
> Or just drop the field name thing, as you suggest.

Would you like another tombstone like the one I made for D. typedef?

Fri, 20 Nov 2009 05:59:21 +0000, dsimcha wrote:

> == Quote from Don (nospam@nospam.com)'s article
>> Now that we have struct literals, the old C-style struct initializers
>> don't seem to be necessary.
>> The variations with named initializers are not really implemented --
>> the example in the spec doesn't work, and most uses of them cause
>> compiler segfaults or wrong code generation. EG... struct Move{
>>     int D;
>> }
>> enum Move genMove = { D:4 };
>> immutable Move b = genMove;
>> It's not difficult to fix these compiler problems, but I'm just not
>> sure if it's worth implementing. Maybe they should just be dropped?
>> (The { field: value } style anyway).
> 
> I'd be inclined to say go for it, because it's yet another crufty
> feature inherited from C that I don't use, was barely aware even
> existed, and has been superseded by a better feature that's unique to D.
>  What can be done with struct initializers that can't be done just as
> easily with struct literals?  As far as I can tell (correct me if I'm
> wrong), nothing.
> 
> IMHO we concern ourselves with C source compatibility and ease of porting C code too much sometimes.  If people want a language that's source compatible with C, they want C++ and they know where to find it. If they want a language that sacrifices backwards compatibility to get rid of tons of cruft, then that's what D is and we shouldn't be ashamed of it.  If we kinda sorta care about C source compatibility, we won't attract either audience.

Well said.

Walter Bright wrote:
> Don wrote:
>> Now that we have struct literals, the old C-style struct initializers don't seem to be necessary.
>> The variations with named initializers are not really implemented -- the example in the spec doesn't work, and most uses of them cause compiler segfaults or wrong code generation. EG...
>>
>> struct Move{
>>    int D;
>> }
>> enum Move genMove = { D:4 };
>> immutable Move b = genMove;
>>
>> It's not difficult to fix these compiler problems, but I'm just not sure if it's worth implementing. Maybe they should just be dropped? (The { field: value } style anyway).
>>
>>
> 
> Funny, I've been thinking the same thing. Those initializers are pretty much obsolete, the only thing left is the field name thing. To keep the field name thing with the newer struct literals would require named function parameters as well, something doable but I'm not ready to do all the work to implement that yet.
> 
> Or just drop the field name thing, as you suggest.

Dropping the whole lot would make it easier to identify delegate literals. I think the code below is quite wierd.

struct A { int x; }
alias void delegate () B;

void bar1(A a) {}
void bar2(B b) {}


void main()
{
  A a = {  };
  B b = {  };

  bar1(a);  // ok
  bar2(b);  // ok
  bar1( {} ); // fails.  And you can't even do:  bar1( cast(A){} );
  bar2( {} ); // ok
}

I suspect that there are all kinds of odd corner cases involving these guys, which haven't been explored.

I've used static struct initializers because somehow the dmd optimizer is able to produce more efficient code. If you replace the C-style static struct initializers in this program with D ones (the ones like Foo(1, 2)) the program gets slower:
http://shootout.alioth.debian.org/debian/benchmark.php?test=nbody&lang=gdc&id=1

Maybe dmd doesn't see D-style static struct initializers as true compile-time constants, I don't know. I think LDC doesn't share this problem/limit.

Bye,
bearophile

bearophile wrote:
> I've used static struct initializers because somehow the dmd
> optimizer is able to produce more efficient code. If you replace the
> C-style static struct initializers in this program with D ones (the
> ones like Foo(1, 2)) the program gets slower: http://shootout.alioth.debian.org/debian/benchmark.php?test=nbody&lang=gdc&id=1
> 
> 
> Maybe dmd doesn't see D-style static struct initializers as true
> compile-time constants, I don't know. I think LDC doesn't share this
> problem/limit.


The generated code should be identical. Please file a bugzilla!

Walter Bright:
> The generated code should be identical. Please file a bugzilla!

The last times I have shown a benchmark here, people have answered me that the dmd backend is primitive/old, so they have implicitly told me to not bother. So as you have noticed I have stopped showing benchmarks here for a long time, and I have focused myself in helping finding performance problems in LDC (and in LLVM itself). Recently LDC devs have slowed down their development, and they have not followed my suggestions, so I'll probably work mostly on LLVM.

Bye,
bearophile

Walter Bright, el 19 de noviembre a las 23:53 me escribiste:
> >It's not difficult to fix these compiler problems, but I'm just not sure if it's worth implementing. Maybe they should just be dropped? (The { field: value } style anyway).
> 
> Funny, I've been thinking the same thing. Those initializers are pretty much obsolete, the only thing left is the field name thing. To keep the field name thing with the newer struct literals would require named function parameters as well, something doable but I'm not ready to do all the work to implement that yet.

Is nice to read that you like the idea of having named function parameters, even when you don't have the time or don't want to implement them :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que importante, entonces en estos días de globalización refregar
nuestras almas, pasarle el lampazo a nuestros corazones para alcanzar
un verdadero estado de babia peperianal.
	-- Peperino Pómoro