headers
4tuu4k002 | 1 Mar 2009 01:27
Picon
Favicon

Unofficial wish list status.(Mar 2009)


Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

Right now the wish list looks like this:

198  Stack tracing (#26)
192  Reflection API (#6)
131  vectorization (#10)
110  Multiple return values (tuples (#28)
98  Multiple opCast per class (#24)
90  Debug check for null reference (#52)
85  Native AMD64 codegen (#36)
77  Short syntax for new (#18)
74  !in (#44)
73  unit test after compilation (#1)
69  extra compiler values (#19)
63  Return-type overloading (#49)
57  Explicit out/inout (#38)
54  Foreach on first/on last (#42)
53  Unit test isolation  (#2)
49  Posix threads support native (#3)
46  Array pushback/popback (#51)
45  Array masking (#11)
45  Variadic arguments re-passing (#102)
44  better syntax for cast (#23)
44  Consistent struct/class sizeof (#40)
41  Explicit type initializers (#35)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ary Borenszweig | 1 Mar 2009 01:28
Picon
Favicon
Gravatar

Re: __FUNCTION__

Andrei Alexandrescu escribió:
> Jarrett Billingsley wrote:
>> On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail <at> erdani.org> wrote:
>>> We better use "..".
>>>
>>>  int factorial(int c)
>>>  {
>>>     //writefln(fthis.stringof);
>>>     //writefln(typeof(fthis).stringof);
>>>
>>>     if (c < 2) return 1;
>>>     return ..(c - 1) * c;
>>>  }
>>
>> I hope this is a sarcastic reply :P
> 
> My second. I was afraid the first one wasn't transparent enough.

The contextual keyword iota, right?

> 
> Andrei
Permalink | Reply | 2 comments |
headers
Tim M | 1 Mar 2009 01:55

Re: Unofficial wish list status.(Mar 2009)

On Sun, 01 Mar 2009 13:27:43 +1300, <4tuu4k002 <at> sneakemail.com> wrote:

>
> Hi
>
> This is the monthly status for the unofficial d wish list:
> http://all-technology.com/eigenpolls/dwishlist/
>
> Right now the wish list looks like this:
>
> 198  Stack tracing (#26)
> 192  Reflection API (#6)
> 131  vectorization (#10)
> 110  Multiple return values (tuples (#28)
> 98  Multiple opCast per class (#24)

http://all-technology.com/eigenpolls/dwishlist/index.php?it=10

Who's idea was the vectorization? Seems very usefull but not sure if  
really like the syntax. Wouldn't it be simpler to have unordered attribute  
for all kinds loops that the compiler can use?
Permalink | Reply | 2 comments |
headers
Andrei Alexandrescu | 1 Mar 2009 02:09

Re: __FUNCTION__

Ary Borenszweig wrote:
> Andrei Alexandrescu escribió:
>> Jarrett Billingsley wrote:
>>> On Sat, Feb 28, 2009 at 4:50 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail <at> erdani.org> wrote:
>>>> We better use "..".
>>>>
>>>>  int factorial(int c)
>>>>  {
>>>>     //writefln(fthis.stringof);
>>>>     //writefln(typeof(fthis).stringof);
>>>>
>>>>     if (c < 2) return 1;
>>>>     return ..(c - 1) * c;
>>>>  }
>>>
>>> I hope this is a sarcastic reply :P
>>
>> My second. I was afraid the first one wasn't transparent enough.
> 
> The contextual keyword iota, right?

That's the one! I think it even got a serious answer :o).

Andrei
Permalink | Reply | 1 comment |
headers
Andrei Alexandrescu | 1 Mar 2009 02:08

Re: __FUNCTION__

Derek Parnell wrote:
> On Sat, 28 Feb 2009 17:42:55 -0500, Jarrett Billingsley wrote:
> 
>> Then, as Andrei suggested, we need a more flexible and fine-grained
>> reflection mechanism.  :)
> 
> Agreed, but are you also suggesting that a simple __FUNCTION__ should also
> exist?
> 
> By the way, my fear for D is that it is turning into an ASCII version of
> APL.
> 

I don't know much about APL, what was wrong with it?

Andrei
Permalink | Reply | 4 comments |
headers
Walter Bright | 1 Mar 2009 02:40
Favicon

Re: __FUNCTION__

Andrei Alexandrescu wrote:
> I don't know much about APL, what was wrong with it?

It needed a special keyboard.
Permalink | Reply | 2 comments |
headers
Christopher Wright | 1 Mar 2009 03:07
Picon

Re: __FUNCTION__

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> I don't know much about APL, what was wrong with it?
> 
> It needed a special keyboard.

There is an input method for APL that supports standard keyboards, I 
believe.
Permalink | Reply | 1 comment |
headers
Walter Bright | 1 Mar 2009 03:18
Favicon

Re: __FUNCTION__

Christopher Wright wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> I don't know much about APL, what was wrong with it?
>>
>> It needed a special keyboard.
> 
> There is an input method for APL that supports standard keyboards, I 
> believe.

Yeah, many kludge-o-matic workarounds have appeared over the years, none 
of which are very satisfactory.
Permalink | Reply | 0 comments |
headers
Edward Diener | 1 Mar 2009 03:35

Re: __FUNCTION__

Andrei Alexandrescu wrote:
> BCS wrote:
>> Hello Andrei,
>>
>>> Nick Sabalausky wrote:
>>>
>>>> Stdout.formatln("{}", __FUNCTION__);
>>>
>>> I think instead of __FUNCTION__ we'll define a much more comprehensive
>>> static reflection facility.
>>>
>>
>> for the above case I think __FUNCTION__ is as good as it will get. 
>> Define it as a human readable identifier rather than reflection.
>>
>>
> 
> You will have it as a human readable identifier too. The problem with
> __FUNCTION__, __CLASS__ etc. is that the list of ad-hoc names (what
> happened to __STRUCT__, __MODULE__ et al?) can go forever.
> 

These macros are the wrong idea. As you say the bare macros can go on 
forever. What is really needed in a reflection library is the ability to 
  'reflect' all D constructs, and you would get much more than just the 
name in such a library.

So pushing for __FUNCTION__, __CLASS__ etc. etc. is just a quick-fix 
solution whereas a real reflection library gives so much more.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Christopher Wright | 1 Mar 2009 04:04
Picon

Re: __FUNCTION__

Andrei Alexandrescu wrote:
> grauzone wrote:
>> For classes and structs, this is already possible: typeof(this).stringof
> 
> Not outside of a member function. This is crippling my Visitor 
> implementation.

I use it in static constructors. If it doesn't work, well, that's news 
to me.

I don't know about "typeof(this) property;", though. I never tried it.

>> Now we only need a way to get some kind of compile time object for 
>> functions and modules (like the type for classes/structs). Then you 
>> simply can use .stringof on them.
> 
> There's much more to reflection that we need to define.

Runtime as well as compile time.
Permalink | Reply | 2 comments |

Gmane