November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 ?
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | 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
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | == 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.
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
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
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | 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?
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | 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
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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.
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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. |
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yigal Chripun | 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
|
November 20, 2009 Re: Can we drop static struct initializers? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Travis Boucher | 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.
|
Copyright © 1999-2021 by the D Language Foundation