Andrei Alexandrescu wrote:
> 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

what about foreach_reverse ?

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

Here's one thing I just found:
struct constructors don't work at compile-time:

struct Struct
{
    this(int _n, float _x) {
        n = _n; x = _x;
    }
    int n;
    float x;
}

enum A = Struct(1,2);

// Error: cannot evaluate ((Struct __ctmp1;
// ) , __ctmp1).this(1,2F) at compile time

The C-style initializer works.
static opCall works too.

But if that bug is fixed, then I can't think of a reason to have the classic C-style no-colons syntax.

--bb

== Quote from Yigal Chripun (yigal100@gmail.com)'s article
> Andrei Alexandrescu wrote:
> > 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
> what about foreach_reverse ?

IMHO this should be dropped as a keyword, but opApplyReverse should be kept. Calling std.range.retro() with a type where iteration works via opApply, not ranges, should cause Retro.opApply to forward to opApplyReverse.  This would preserve consistency between iterating over ranges and opApply types and get rid of a really ugly keyword.

On Fri, Nov 20, 2009 at 10:58 AM, Bill Baxter <wbaxter@gmail.com> wrote:
> 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);

I should say that I won't really shed a tear over loss of the current
static-only  {a:b} syntax.
But I would like to see something similar resurrected as a fully
dynamic construct for the use case of large numbers of options with
good defaults for most.

I see no reason the compiler shouldn't be able to turn

runAlgo( Options{verbosity:100} );

into

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

--bb

On Fri, Nov 20, 2009 at 11:15 AM, Yigal Chripun <yigal100@gmail.com> wrote:

> what about foreach_reverse ?
>

What about starting a different thread?

Yigal Chripun wrote:
> Andrei Alexandrescu wrote:
>> 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
> 
> what about foreach_reverse ?

FWIW iota is written to work better with retro on floating-point numbers than foreach_reverse. However, it does one addition and one multiplication per iteration; foreach_revers only does one addition. The multiplication, however, gives iota precise semantics.

Andrei

Bill Baxter wrote:
> On Fri, Nov 20, 2009 at 11:15 AM, Yigal Chripun <yigal100@gmail.com> wrote:
> 
>> what about foreach_reverse ?
>>
> 
> What about starting a different thread?

Sorry.
I assumed we were discussing removals from D and therefore mentioned foreach_reverse as a prime candidate. I'll start a new thread.

Andrei Alexandrescu, el 20 de noviembre a las 10:42 me escribiste:
> 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,

C-style comma operator is gone, ... no, wait. I'm dreaming =P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
No existiría el sonido del mar si faltara en la vida oreja y caracol.
	-- Ricardo Vaporeso. Cosquín, 1908.

On Fri, Nov 20, 2009 at 11:55 AM, Yigal Chripun <yigal100@gmail.com> wrote:
> Bill Baxter wrote:
>>
>> On Fri, Nov 20, 2009 at 11:15 AM, Yigal Chripun <yigal100@gmail.com> wrote:
>>
>>> what about foreach_reverse ?
>>>
>>
>> What about starting a different thread?
>
> Sorry.
> I assumed we were discussing removals from D and therefore mentioned
> foreach_reverse as a prime candidate. I'll start a new thread.

No prob.  Just that people interested in the topic may not see your message if it's buried under the heading of "static struct initializers".

--bb

Travis Boucher wrote:
> 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?).

gdc and ldc connect the dmd frontend with free backends.
Of course, it gets harder to send Walter a patch in this case, and I would expect that such a patch is simply ignored.