> I'm not much of a template guy .. good job, I guess, even though it all
> sounds like C++ish bloat to me.
> But isn't Reflection more important? :P

Template programming will be used primarily to develop sophisticated libraries to be used by people like you who don't like template programming. Using a template and developing one are two very different things.  The typical developer might just shrug at advanced template features, but an advanced library developer will appreciate them very much.

BTW, C++ doesn't even come close to having these features.

-Craig

Walter Bright wrote:
> Much improved tuple support.
> 
> New 'scope' attribute for RAII objects. 'auto' still works the same, but will not for much longer. Use 'auto' for type inference.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.174.zip

deprecated 'l' numeric literal suffix no longer allowed

I always use 'l' for 32 bits signed values.

now... Walters deprecates my prefix styling... thank you.

Absurd.

Walter:  change your editor, your font or, simply, don't use 'l' prefix... but don't deprecate me, please.

Walter Bright wrote:
> Much improved tuple support.
> 
> New 'scope' attribute for RAII objects. 'auto' still works the same, but will not for much longer. Use 'auto' for type inference.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.174.zip

Nice release!

Jarrett Billingsley wrote:
> "Kirk McDonald" <kirklin.mcdonald@gmail.com> wrote in message news:ejeepp$15n1$1@digitaldaemon.com...
>> Jarrett Billingsley wrote:
>>> A few questions:
>>>
>>> 1) For the delegate .funcptr property, would it be possible for it to include the context pointer as the first parameter?  Currently the .funcptr allows us to get the type / call signature of the delegate but it's not possible to actually use the resulting function as there is no way to pass it the context short of dipping into ASM..
>>>
>> Not so: Walter added a .ptr property to delegates in 0.168. Between that and .funcptr, you've got all you need to mess with delegates right there.
> 
> Well even with the context pointer, how do you propose passing it to the resulting func pointer?  The context is passed implicitly as the first parameter to any delegate, and without that first parameter in the parameter list, you can't pass the context.  So
> 
> class A { void fork(int x) { } }
> 
> A a = new A();
> auto dg = &a.fork;
> auto fp = dg.funcptr;
> 
> fp(3); // access violation
> 
> What's worse is that because the parameter list doesn't include the context, trying to call fp will result in all the arguments being shifted down a position from where they should be, i.e. 3 will now be in the 'this' slot, and nothing useful will be in the 'x' slot.  :S  So you _have_ to use ASM to call that func pointer, or maybe use some template trickery to create a pointer to the function with an extra first param. 
> 
> 
I'm not sure if this is what you want, but here's a cast-free 'call' function:

import std.stdio : writefln;

class A {
    int a_m;
    this(int a)
    {
        this.a_m = a;
    }
    void fork(int b)
    {
        writefln(a_m,b);
    }
}

void main()
{
    A a = new A(1);
    A b = new A(2);
    auto dg = &a.fork;
    auto fp = dg.funcptr;

    call(fp, a, 3); // Prints 13
    call(fp, b, 3); // Prints 23
}

B call(A, B, Params...)(B function (Params) fp, A a, Params p)
{
    B delegate(Params) dg;
    dg.funcptr = fp;
    dg.ptr = a;
    return dg(p);
}

antonio wrote:
> deprecated 'l' numeric literal suffix no longer allowed
> 
> I always use 'l' for 32 bits signed values.
> 
> now... Walters deprecates my prefix styling... thank you.
> 
> Absurd.
> 
> Walter:  change your editor, your font or, simply, don't use 'l' prefix... but don't deprecate me, please.

The 'l' suffix was to indicate a long type. You mentioned prefix, not suffix. I think we are talking about different things.

Walter Bright wrote:
> antonio wrote:
>> deprecated 'l' numeric literal suffix no longer allowed
>>
>> I always use 'l' for 32 bits signed values.
>>
>> now... Walters deprecates my prefix styling... thank you.
>>
>> Absurd.
>>
>> Walter:  change your editor, your font or, simply, don't use 'l' prefix... but don't deprecate me, please.
> 
> The 'l' suffix was to indicate a long type. You mentioned prefix, not suffix. I think we are talking about different things.

Yes, sorry.
Stupidity is usually related with sleepy people.

"Reiner Pope" <reiner.pope@REMOVE.THIS.gmail.com> wrote in message news:ejg8qd$475$1@digitaldaemon.com...
> Jarrett Billingsley wrote:

> I'm not sure if this is what you want, but here's a cast-free 'call' function:
>
> ...code...

Ah!  That's an alright tradeoff.  I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only!  Cool.

Jarrett Billingsley wrote:
> Ah!  That's an alright tradeoff.  I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only!  Cool. 

I suppose my background in tinkering with cars shows here <g>.

Walter Bright wrote:
> Stewart Gordon wrote:
<snip>
>> 4. Why do ForStatement and ForeachStatement now take a NoScopeNonEmptyStatement as body, rather than a ScopeStatement?
> 
> The scope is created by the for initialization, not the body.

So the whole ForStatement creates a scope, and Initialize, Test, Increment and the statement body all share this scope?  This ought to be a little clearer.  The way it's written at the moment ("that variable's scope extends through the end of NoScopeNonEmptyStatement") looks like a contradiction.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Jarrett Billingsley wrote:
> "Reiner Pope" <reiner.pope@REMOVE.THIS.gmail.com> wrote in message news:ejg8qd$475$1@digitaldaemon.com...
> 
>>Jarrett Billingsley wrote:
> 
> 
>>I'm not sure if this is what you want, but here's a cast-free 'call' function:
>>
>>...code...
> 
> 
> Ah!  That's an alright tradeoff.  I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only!  Cool. 
> 
> 

I didn't know this either... and it opens some ideas up to me...  Like, perhaps one could do the following:

# class Foo {
#   void bar () { ... }
# }
#
# Foo[] list = ... ;
# auto dg = &list[0].bar;
# dg();
# foreach (x; list[1 .. $]) {
#   dg.ptr = x;
#   dg();
# }

Might actually be slightly cheaper than a normal call in some cases, particularly of Foo and/or bar() are final.  Will have to test it...

-- Chris Nicholson-Sauls