I have an Anti-Big Feature request; that is, a request against new features.

When this const issue will finally be solved to most peoples' satisfaction, kindly consider inserting a period of consolidation.

No more sudden, game-changing new super features for a while.
Maybe fix some long-standing bugs.
Maybe finally implement the generational GC.
Maybe actually get DbC inheritance to work like it's supposed to.
Maybe give memory back to the OS on occasion.
Maybe revisit some 1.0 concepts and consider if they're still needed.
Maybe add small things everybody can agree are good (return type deduction comes to mind).
Aim for low-hanging fruits, stuff we can agree on for once.
How about a redundancy free import syntax?

D's 2.0 series has been characterized by a series of fundamental changes (const, closures),
but what really makes a new release great is the polish. Small stuff everybody looks forward to.
Clean up the issues with the OMF tools? Maybe even consider switching to PE?
(Heresy, I know; however, it is fact that GDC has no problem with megabyte-long symbol names)

Oh, and please, delay the AST macros for a while. My head is still spinning with closures. :)
 --downs

PS:
  Personal wish list:
    * Struct copy semantics, lazy and ref storage types
    * a way to detect ref in a delegate parameter list
    * Improved compile-time information for enums
    * TRACED EXCEPTIONS ;____; yeah I wish
    * Allow inheriting from superclasses' nested classes

PPS: Representative sentiment from #d:
>
> <fundesktop> a stable, feature complete compiler without bugs and good additional tools <fundesktop> SOMETHING WHICH D WILL NEVER GET
>

"downs" <default_357-line@yahoo.de> wrote in message news:fjv3hq$15gd$1@digitalmars.com...
>I have an Anti-Big Feature request; that is, a request against new features.
>
> When this const issue will finally be solved to most peoples'
> satisfaction,
> kindly consider inserting a period of consolidation.
>
> No more sudden, game-changing new super features for a while.
> Maybe fix some long-standing bugs.
> Maybe finally implement the generational GC.
> Maybe actually get DbC inheritance to work like it's supposed to.
> Maybe give memory back to the OS on occasion.
> Maybe revisit some 1.0 concepts and consider if they're still needed.
> Maybe add small things everybody can agree are good (return type deduction
> comes to mind).
> Aim for low-hanging fruits, stuff we can agree on for once.
> How about a redundancy free import syntax?
>
> D's 2.0 series has been characterized by a series of fundamental changes
> (const, closures),
> but what really makes a new release great is the polish. Small stuff
> everybody looks forward to.
> Clean up the issues with the OMF tools? Maybe even consider switching to
> PE?
> (Heresy, I know; however, it is fact that GDC has no problem with
> megabyte-long symbol names)
>
> Oh, and please, delay the AST macros for a while. My head is still
> spinning with closures. :)
> --downs

Agreed on (virtually) every count.

> PS:
>  Personal wish list:
>    * TRACED EXCEPTIONS ;____; yeah I wish

Huh!  Tango's had those for months.

Yeah.  What.

Reply to Downs,

[goood stuff]

Yup. There are a few bugs I'd like to see fixed to.


> Clean up the issues with the OMF tools? Maybe even consider switching
> to PE?
> (Heresy, I know; however, it is fact that GDC has no problem with
> megabyte-long symbol names)

BTW, Why isn't this getting fixed? people known how to fix this, several solutions have been thrown out there. this should have been fixed a long time ago.

here's my take on it:

If the symbol is over 1Kb*, MD5 it or something and use that. Hash them down to 128bits and your chances of collision are so remote it's not even worth thinking about.  If you need to be able to go back to the original, stuff a table in the .obj that maps the two. This wouldn't make for human readable link errors but the gzipping that is used now doesn't either. 

* or pick your size

Jarrett Billingsley wrote:
> "downs" <default_357-line@yahoo.de> wrote in message news:fjv3hq$15gd$1@digitalmars.com...
>> I have an Anti-Big Feature request; that is, a request against new features.
>>
>> When this const issue will finally be solved to most peoples' satisfaction,
>> kindly consider inserting a period of consolidation.
>>
>> No more sudden, game-changing new super features for a while.
>> Maybe fix some long-standing bugs.
>> Maybe finally implement the generational GC.
>> Maybe actually get DbC inheritance to work like it's supposed to.
>> Maybe give memory back to the OS on occasion.
>> Maybe revisit some 1.0 concepts and consider if they're still needed.
>> Maybe add small things everybody can agree are good (return type deduction comes to mind).
>> Aim for low-hanging fruits, stuff we can agree on for once.
>> How about a redundancy free import syntax?
>>
>> D's 2.0 series has been characterized by a series of fundamental changes (const, closures),
>> but what really makes a new release great is the polish. Small stuff everybody looks forward to.
>> Clean up the issues with the OMF tools? Maybe even consider switching to PE?
>> (Heresy, I know; however, it is fact that GDC has no problem with megabyte-long symbol names)
>>
>> Oh, and please, delay the AST macros for a while. My head is still spinning with closures. :)
>> --downs
> 
> Agreed on (virtually) every count.
> 
>> PS:
>>  Personal wish list:
>>    * TRACED EXCEPTIONS ;____; yeah I wish
> 
> Huh!  Tango's had those for months.
> 
> Yeah.  What. 

I'm looking into giving memory back to the OS as well.  It will take some re-engineering of the GC, but it seems quite doable.


Sean

downs wrote:
>     * a way to detect ref in a delegate parameter list

Huh. After writing this, in a sudden flash of insight, I reinvented a method that has been in use in std.bind for ages now (props to h3).

Consider the following code:

>
> template _isRef(C, size_t which) {
>   alias ParameterTypeTuple!(C) pt;
>   pt[0..which] pre;
>   const pt[which] test;
>   pt[which+1..$] post;
>   const bool r=!is(typeof(C(pre, test, post)));
> }
> template isRef(C, size_t which) { const bool isRef=_isRef!(C, which).r; }
>


What does this mean?
Succinctly put, if (and only if) a parameter is ref, then trying to call
the delegate/function type in question with a constant value for that parameter
will fail. The const bool r expression literally means "true if calling C with
a constant test fails to produce a return value".

Should there be a place to collect metaprogramming thingies like this so people don't have to reinvent the wheel?

 I vote std.meta! :)


 --downs

downs Wrote:

> I have an Anti-Big Feature request; that is, a request against new features.
> 
> When this const issue will finally be solved to most peoples' satisfaction, kindly consider inserting a period of consolidation.
> 
> No more sudden, game-changing new super features for a while.
> Maybe fix some long-standing bugs.
> Maybe finally implement the generational GC.
> Maybe actually get DbC inheritance to work like it's supposed to.
> Maybe give memory back to the OS on occasion.
> Maybe revisit some 1.0 concepts and consider if they're still needed.
> Maybe add small things everybody can agree are good (return type deduction comes to mind).
> Aim for low-hanging fruits, stuff we can agree on for once.
> How about a redundancy free import syntax?
> 
> D's 2.0 series has been characterized by a series of fundamental changes (const, closures),
> but what really makes a new release great is the polish. Small stuff everybody looks forward to.
> Clean up the issues with the OMF tools? Maybe even consider switching to PE?
> (Heresy, I know; however, it is fact that GDC has no problem with megabyte-long symbol names)
> 
> Oh, and please, delay the AST macros for a while. My head is still spinning with closures. :)
>  --downs
> 
> PS:
>   Personal wish list:
>     * Struct copy semantics, lazy and ref storage types
>     * a way to detect ref in a delegate parameter list
>     * Improved compile-time information for enums
>     * TRACED EXCEPTIONS ;____; yeah I wish
>     * Allow inheriting from superclasses' nested classes
> 
> PPS: Representative sentiment from #d:
> >
> > <fundesktop> a stable, feature complete compiler without bugs and good additional tools <fundesktop> SOMETHING WHICH D WILL NEVER GET
> >

votes++;

If I could add something to the "small things" wishlist:
A pragma to tell the compiler to inline all occurences of a function and not generate its body in the object file separately. It could unclutter generated code from numerous useless proxy or otherwise simple functions that don't do much, but get generated in flocks for example in template expansion. Could also be used to prevent functions meant solely for CTFE from ending up in the binary.

downs wrote:
> 
> Should there be a place to collect metaprogramming thingies like this so people
> don't have to reinvent the wheel?
> 
>  I vote std.meta! :)

hehe... Tango had a meta package until CTFE came along and rendered the bulk of it pointless.  This particular routine would make sense in std.traits though.


Sean

BCS wrote:
> Reply to Downs,
> 
> [goood stuff]
> 

Hear! Hear!
Hear the voices of calmness & tranquility!

=)

Kind regards, frank

Hxal Wrote:

> downs Wrote:
> 
> > I have an Anti-Big Feature request; that is, a request against new features.
> > 
> > When this const issue will finally be solved to most peoples' satisfaction, kindly consider inserting a period of consolidation.
> > 
> > No more sudden, game-changing new super features for a while.
> > Maybe fix some long-standing bugs.
> > Maybe finally implement the generational GC.
> > Maybe actually get DbC inheritance to work like it's supposed to.
> > Maybe give memory back to the OS on occasion.
> > Maybe revisit some 1.0 concepts and consider if they're still needed.
> > Maybe add small things everybody can agree are good (return type deduction comes to mind).
> > Aim for low-hanging fruits, stuff we can agree on for once.
> > How about a redundancy free import syntax?
> > 
> > D's 2.0 series has been characterized by a series of fundamental changes (const, closures),
> > but what really makes a new release great is the polish. Small stuff everybody looks forward to.
> > Clean up the issues with the OMF tools? Maybe even consider switching to PE?
> > (Heresy, I know; however, it is fact that GDC has no problem with megabyte-long symbol names)
> > 
> > Oh, and please, delay the AST macros for a while. My head is still spinning with closures. :)
> >  --downs
> > 
> > PS:
> >   Personal wish list:
> >     * Struct copy semantics, lazy and ref storage types
> >     * a way to detect ref in a delegate parameter list
> >     * Improved compile-time information for enums
> >     * TRACED EXCEPTIONS ;____; yeah I wish
> >     * Allow inheriting from superclasses' nested classes
> > 
> > PPS: Representative sentiment from #d:
> > >
> > > <fundesktop> a stable, feature complete compiler without bugs and good additional tools <fundesktop> SOMETHING WHICH D WILL NEVER GET
> > >
> 
> votes++;
> 
> If I could add something to the "small things" wishlist:
> A pragma to tell the compiler to inline all occurences of a function and not generate its body in the object file separately. It could unclutter generated code from numerous useless proxy or otherwise simple functions that don't do much, but get generated in flocks for example in template expansion. Could also be used to prevent functions meant solely for CTFE from ending up in the binary.
> 

Yeah, really, "inline" should be a function attribute, never a file attribute, and it should be used.  That said, I too am pretty tired of major compiler changes.

At the moment, Walnut cannot compile with DMD 1.21 or later because of some bug or unmentioned feature implemented in that version.  It has something to do with

struct Value {
  union {
   struct {}
   int i;
   bool b;
   char[] c;
  bla bla.
}

and later doing something with b.  I'd be able to say more, but the error message is 100% ambiguous and doesn't mention a file or line number.

The exact string I get looks like:

C:\Code\walnut>make
dmd bla bla bla
Error: 'b' is not a member of 'Value'

--- errorlevel 1

Regards,
Dan

On 12/15/07, downs <default_357-line@yahoo.de> wrote:
> Should there be a place to collect metaprogramming thingies like this so people don't have to reinvent the wheel?
>
>  I vote std.meta! :)

I would have thought std.traits.