Leandro Lucarella wrote:
> 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 :)
> 

Whats even nicer is that dmd front end and back end are open source allowing anyone to implement them if they really want to.

Of course it will be even nicerer once the back end is at a state where it can be under a less restrictive license (single user, no redistribution? seriously?).

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

Would love to. At least we can deprecate them and not mention them in TDPL.

Andrei

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 love to trim the book as well. My finger is on the Del button. Just say a word.

Andrei

On Thu, Nov 19, 2009 at 9:48 PM, Don <nospam@nospam.com> 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).

I agree there are too many ways to make structs, but...

1) Struct literals don't work if you have an opCall for your struct.
    (Maybe that's not such a big deal now that structs have
constructors?  I haven't had a chance to look into struct constructors
yet...)

2) The field:value style struct initializer is probably the closest D will ever get to named arguments.  I think perhaps it should require the struct name, and be treated as a struct literal rather than static initializer:

      auto anS = S{D:4};   <=>   auto anS = S(4)

--bb

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:he61b9$2i9n$1@digitalmars.com...
> 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

It may be frustrating trying to get others to be as performance-minded as you are, but I for one appreciated very much any contributions that will make D faster.  So thanks for trying, even if your advice is ignored.

-Craig 

Andrei Alexandrescu wrote:
> Would love to trim the book as well. My finger is on the Del button. Just say a word.

Unless someone comes up with "I really need field names", dump 'em (but save a backup of your work first!).

Bill Baxter wrote:
> 1) Struct literals don't work if you have an opCall for your struct.
>     (Maybe that's not such a big deal now that structs have
> constructors?  I haven't had a chance to look into struct constructors
> yet...)

Worst case, you can still construct them dynamically.

> 2) The field:value style struct initializer is probably the closest D
> will ever get to named arguments.  I think perhaps it should require
> the struct name, and be treated as a struct literal rather than static
> initializer:
> 
>       auto anS = S{D:4};   <=>   auto anS = S(4)

I think we'd need a compelling use case for why this is needed.

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Would love to trim the book as well. My finger is on the Del button. Just say a word.
> 
> Unless someone comes up with "I really need field names", dump 'em (but save a backup of your work first!).

My RIP emails to you (as with typedef) are my backup. Don't delete them :o).

So, C-style arrays are gone, C-style struct initializers are gone, typedef is gone. __traits isn't feeling too well either :o).


Andrei

On Fri, Nov 20, 2009 at 10:29 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> 1) Struct literals don't work if you have an opCall for your struct.    (Maybe that's not such a big deal now that structs have constructors?  I haven't had a chance to look into struct constructors yet...)
>
> Worst case, you can still construct them dynamically.
>
>> 2) The field:value style struct initializer is probably the closest D will ever get to named arguments.  I think perhaps it should require the struct name, and be treated as a struct literal rather than static initializer:
>>
>>      auto anS = S{D:4};   <=>   auto anS = S(4)
>
> I think we'd need a compelling use case for why this is needed.

This is the main use case I have in mind:

void runAlgo(Options opt);

struct Options {
    bool useFrobbing = false;
    int numIters = 200;
    float tolerance = 1e-4;
    int verbosity = 0;
    // ...
 }

runAlgo( Options{verbosity:100} );

instead of

Options opt;
opt.verbosity = 100;
runAlgo(opt);

--bb

On Nov 21, 09 00:15, Andrei Alexandrescu wrote:
> 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 love to trim the book as well. My finger is on the Del button.
> Just say a word.
>
> Andrei

Maybe C-style function pointer types (i.e. void(*f)(void*))? ;)