"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:djohp1$2rnq$1@digitaldaemon.com...
> pragma wrote:
>> In article <djjpa0$1o9n$2@digitaldaemon.com>, Walter Bright says...
>>> A couple of oft-requested features.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>> Walter,
>> I think others have brought this up, but there's a problem with
>> overloading the
>> use of 'auto' in this way.  If one wants to have both RAII *and*
>> auto-type
>> capabilities in the same statement, it can't be done since they both use
>> the
>> same keyword.
> <snip>
>
> You've got me wondering what practical use this auto-type facility has. Just syntactic sugar for
>
>     typeof(4u) y = 4u;
>
> ?

If it spares one from having to write the type twice -- first for the declaration, then for the initialisation -- then I think it's a welcome addition. And while it may not seem a huge deal, already I have saved time by cutting down on errors made keying in template and delegate declarations.

For example, I'm often unsure which of these two is correct because the way one declares and initialises a delegate differs:

    delegate int(char[]) d = delegate int(char[] s) { ... };

or

    int delegate(char[]) d = delegate int(char[] s) { ... };

And I won't find out that the first is incorrect until I compile. But using auto I'll not have to fix and recompile:

    auto d = delegate int(char[] s) { ... };

Plus if I change the signature of the delegate, I need do it only in one place. I know some will disagree, but I also think this is more readable.

John.

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

In article <djodvq$2nvh$3@digitaldaemon.com>, Walter Bright says...
>
>
>"Vathix" <chris@dprogramming.com> wrote in message news:op.sy8x7py7l2lsvj@esi...
>> I like it. Only problem I can think of is conflicts if the class has a static opCall. Perhaps classes should not have them
>
>I'm hard pressed to see the point of them for classes anyway.
>
>> (but they're very
>> handy for structs/unions). This extra code in the compiler to support it
>> could possibly be hacked in by adding an internal, implicit static opCall
>> to all classes, which are translated to RAII constructors when invoked
>>  from an initializer ;)
>
>There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.
>

Could we do stuff like this (w/o the new/delete member overrides)?:

;---

-import std.c.stdlib, std.stdio;
-
-void main()
-{
-    // imagine 'f' is constructed like:
-    // auto f = Foo(100);
-    Foo f = new(std.c.stdlib.alloca(Foo.classinfo.init.length)) Foo(100);
-    for(int i = 0; i < 100; i++)
-    {
-        f.x *= i + 1;
-        writefln(f.x);
-        Foo f2 = foo(f);
-        writefln(f2.x,"\n");
-    }
-}
-
-Foo foo(Foo f)
-{
-    f.x *= 3.14159;
-    return f;
-}
-
-class Foo
-{
-    double x;
-    this(double x)
-    {
-        this.x = x;
-    }
-    new(uint sz, void *p)
-    {
-	return p;
-    }
-    delete(void* p)
-    {
-	assert(0);
-    }
-}

Thanks,

- Dave

"Walter Bright" <newshound@digitalmars.com> wrote in message news:djlu50$agr$1@digitaldaemon.com...
>
> "John Reimer" <terminal.node@gmail.com> wrote in message news:djlrjv$3pl$1@digitaldaemon.com...
>> Yay!
>>
>> "extern(linkage) for nested functions now works."
>>
>> Thanks, Walter!  I thought you had all but forgotten this one.
>
> I just kept getting distracted onto other things. Sorry it took so long.
>
>

No problem!  You certainly have plenty to distract you. :-)

One note, though.  It won't work in it's current form.  Having the ability to apply extern(linkage) for nested functions is primarily useful for OS callback methods; but as implemented right now, this is not possible because the nested functions are seen solely as /delegates/ not /function pointers/. See the following:

module callback;

extern(Windows) alias int function(int,int) UPDATE_EVENT_W;

// Simulate external win32 call
extern(Windows) int extfunction( UPDATE_EVENT_W func )
{
 // do nothing
 auto fw = func;
 return 1;
}

void init( UPDATE_EVENT_W fc )
{
 extern(Windows) int func1( int a, int b )
 {
  if (fc !is null)
   fc( a, b );
 }
 extfunction( &func1 );
}

That code produces the following compile message:

callback.d(20): function callback.extfunction (int(Windows *)(int, int))
does not match argument types (int de
legate(int a, int b))
callback.d(20): cannot implicitly convert expression (&func1) of type int
delegate(int a, int b) to int(Window
s *)(int, int)

Is it possible to fix this?

Also it appears that extern(Linkage) {} still won't work and defining function literals with a linkage attribute is also impossible.

Thanks!

-John

In article <djoo2b$lv$1@digitaldaemon.com>, John Reimer says...
>
>One note, though.  It won't work in it's current form.  Having the ability to apply extern(linkage) for nested functions is primarily useful for OS callback methods; but as implemented right now, this is not possible because the nested functions are seen solely as /delegates/ not /function pointers/.

Try this:

>void init( UPDATE_EVENT_W fc )
>{
> extern(Windows) int func1( int a, int b )

static extern(Windows) int func1( int a, int b )


Sean

Walter Bright wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message
> news:djnlj6$1nbv$1@digitaldaemon.com...
> 
>>But I must say I too don't like having auto (type) share the same name
>>as the unrelated (RAII) auto. Not only it has now that pratical problem
>>of not being able to declare an "auto auto" object, but conceptually as
>>well I don't think it's good to have two keywords with the same name who
>>do quite different things. (remeber C's static ... ugh :P )
> 
> 
> But I think it is completely related! All 'auto' declarations will be
> destroyed when they go out of scope. Remember that class declarations only
> give references to class objects, not class objects themselves. So,
> class(args) creates a stack class object, which is destroyed when it goes
> out of scope. new class(args) creates one on the heap, which is not.
> 
> 
Whoa, you lost me there. Are you talking about the current DMD.127 situation, or your alternative proposal? It seems you are talking about your new proposal, however that (quoted) comment of mine was relative to the current DMD.127 situation.
I'm still kinda lost because the following statement will be false nomatter what situation you were refering to: "All 'auto' declarations will be destroyed when they go out of scope." (I assume "'auto' declaration" is any with a 'auto' keyword in there)
There is an error or misunderstanding here somewhere.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Geesh - see code correction below..

In article <djoku3$2v3p$1@digitaldaemon.com>, Dave says...
>
>In article <djodvq$2nvh$3@digitaldaemon.com>, Walter Bright says...
>>
>>There's more work to get all the details ironed out, but that is where I want to go. It's needed because there are a certain class of problems D doesn't work well without.
>>
>
>Could we do stuff like this (w/o the new/delete member overrides)?:
>
>;---
>
>-import std.c.stdlib, std.stdio;
>-
>-void main()
>-{
>-    // imagine 'f' is constructed like:
>-    // auto f = Foo(100);
>-    Foo f = new(std.c.stdlib.alloca(Foo.classinfo.init.length)) Foo(100);
>-    for(int i = 0; i < 100; i++)
>-    {
>-        f.x *= i + 1;
>-        writefln(f.x);
>-        Foo f2 = foo(f);
>-        writefln(f2.x,"\n");
>-    }
>-}
>-

-Foo foo(Foo f)
-{
-    // imagine 'f2' is constructed like:
-    // Foo f2 = Foo(10);
-    Foo f2 = new(alloca(Foo.classinfo.init.length)) Foo(10);
-    f2.x *= f.x * 3.14159;
-    return f2;
-}


What I meant to ask is will we be able to return stack allocated class instances from functions?

>-
>-class Foo
>-{
>-    double x;
>-    this(double x)
>-    {
>-        this.x = x;
>-    }
>-    new(uint sz, void *p)
>-    {
>-	return p;
>-    }
>-    delete(void* p)
>-    {
>-	assert(0);
>-    }
>-}
>
>Thanks,
>
>- Dave
>
>

In article <djopo5$29m$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <djoo2b$lv$1@digitaldaemon.com>, John Reimer says...
>>
>>One note, though.  It won't work in it's current form.  Having the ability to apply extern(linkage) for nested functions is primarily useful for OS callback methods; but as implemented right now, this is not possible because the nested functions are seen solely as /delegates/ not /function pointers/.
>
>Try this:
>
>>void init( UPDATE_EVENT_W fc )
>>{
>> extern(Windows) int func1( int a, int b )
>
>static extern(Windows) int func1( int a, int b )
>
>
>Sean
>
>

I tried that already and numerous other combinations.  Nothing worked.

Did you actually get that to work?

-JJR

In article <djp8g4$fj9$1@digitaldaemon.com>, John Reimer says...
>
>I tried that already and numerous other combinations.  Nothing worked.
>
>Did you actually get that to work?

I didn't try it.  I know that 'static' is supposed to make local delegates into nonlocal functions and figured it was worth a shot.  I'll try to find some time to mess with it tomorrow.

Sean

"Carlos Santander" <csantander619@gmail.com> wrote in message news:djmpd1$25oa$1@digitaldaemon.com...
> Walter Bright escribió:
>> "Sai" <Sai_member@pathlink.com> wrote in message news:djm1oj$p58$1@digitaldaemon.com...
>>
>>>Is the answer for it is to use a new keyword or to make the compiler
>>
>> smarter ?
>>
>> It's implementing class objects on the stack with the:
>>     classname(constructor arguments)
>> syntax. Then, an RAII class object would be:
>>
>>     auto c = classname(arguments);
>>
>
> Regarding this case, what's gonna happen if "static classname.opCall(whatever)" has been defined?

I'm not really sure, but I guess you'll need an instance of a class for opCall to apply; there's no ambiguity here since the (..) applies to the class name. If I understood his comments correclty, Walter's not going to support  classname c(arguments)  for class construction.

L.

"John C" <johnch_atms@hotmail.com> wrote in message news:djokmm$2upu$1@digitaldaemon.com...
> Plus if I change the signature of the delegate, I need do it only in one place. I know some will disagree, but I also think this is more readable.

Right. This reduces the need for typedef's. It can also reduce bugs that happen when one changes the types in components of an initializer, but fail to correct all the uses of those components, yet with implicit conversions the error may get hidden.