• Charlie (11/11) May 25 2006 1) No operator function opIn(). Everyone loves this operator why not
• Tom (4/9) May 25 2006 Yeah, this was discussed ~100 times. I hope it to be fixed soon.
• Hasan Aljudy (6/11) May 25 2006 auto can mean many many things!!
• BCS (16/34) May 25 2006 IIRC that would be:
• Norbert Nemec (6/45) May 27 2006 Maybe that common confusion could be lifted by introducing a new storage
• Jarrett Billingsley (17/22) May 27 2006 We already have it; it's called "auto" ;) That's exactly what auto mea...
• kris (4/18) May 27 2006 Are you kidding? RAII is about as self explanatory as a goat in a
• Roald Ribe (7/26) May 27 2006 I agree with you on raii. But I think local would be the optimal
• Norbert Nemec (11/33) May 28 2006 Sorry, but I disagree:
• Jarrett Billingsley (23/31) May 28 2006 And before RAII classes came along, 'auto' already had a meaning then to...
• Tom S (19/19) May 28 2006 Maybe something along the lines of one older proposal ?
• Sean Kelly (12/26) May 25 2006 For what it's worth, the next iteration of C++ will use 'auto' to denote...
• Lionello Lunesu (8/14) May 26 2006 or using the already available new() syntax:

Charlie <noone nowhere.com> writes:

1)  No operator function opIn().  Everyone loves this operator why not 
let us overload it ?  Its the only operator we can't overload.

2)  auto auto foo = new Class;  The current double meaning of auto won't 
  allow for both a RAII and type-deduced variable declaration.  I think 
every other language use's 'var' or similar ( var gets my vote, used in 

class 'auto''.

3)  Not really an inconsistency	, but I recently ran into this one 
_again_ http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/36922 .

Thanks for listening,
Charles

Tom <ihate spam.com> writes:

Charlie escribió:

 2)  auto auto foo = new Class;  The current double meaning of auto won't 
  allow for both a RAII and type-deduced variable declaration.  I think 
 every other language use's 'var' or similar ( var gets my vote, used in 

 class 'auto''.

Yeah, this was discussed ~100 times. I hope it to be fixed soon.

--
Tom;

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Charlie wrote:
 2)  auto auto foo = new Class;  The current double meaning of auto won't 
  allow for both a RAII and type-deduced variable declaration.  I think 
 every other language use's 'var' or similar ( var gets my vote, used in 

 class 'auto''.

auto can mean many many things!!

I prefer to get rid of auto all together.
for automatic type inference ==> use 'var'
for RAII, hmm, maybe use something like 'raii'

BCS <BCS pathlink.com> writes:

Hasan Aljudy wrote:
 Charlie wrote:
 
 2)  auto auto foo = new Class;  The current double meaning of auto 
 won't  allow for both a RAII and type-deduced variable declaration.  I 
 think every other language use's 'var' or similar ( var gets my vote, 

 storage class 'auto''.

 
 
 auto can mean many many things!!
 
 I prefer to get rid of auto all together.
 for automatic type inference ==> use 'var'
 for RAII, hmm, maybe use something like 'raii'
 

 
 

IIRC that would be:

#raii foo = new Foo;

the "auto" dosn't indicate auto typing, it's just a storage classe to 
indecate a decleration. "auto" is used because most of the time it has 
no effect.

These all works:

void main()
{
         auto f2 = cast(int)'\n';
         const f3 = cast(int)'\n';
         extern f5 = cast(int)'\n';
         static f8 = cast(int)'\n';
         synchronized f9 = cast(int)'\n';
}

see http://www.digitalmars.com/d/declaration.html#AutoDeclaration

Norbert Nemec <Norbert Nemec-online.de> writes:

BCS wrote:
 Hasan Aljudy wrote:
 Charlie wrote:

 2)  auto auto foo = new Class;  The current double meaning of auto
 won't  allow for both a RAII and type-deduced variable declaration. 
 I think every other language use's 'var' or similar ( var gets my

 'redundant storage class 'auto''.


 auto can mean many many things!!

 I prefer to get rid of auto all together.
 for automatic type inference ==> use 'var'
 for RAII, hmm, maybe use something like 'raii'



 IIRC that would be:
 
 #raii foo = new Foo;
 
 the "auto" dosn't indicate auto typing, it's just a storage classe to
 indecate a decleration. "auto" is used because most of the time it has
 no effect.

Maybe that common confusion could be lifted by introducing a new storage
class (e.g. "local" or "var") indicating a "plain old local variable".
This would be the default for any variable declared with a type and
without storage class, but it would be useful in declaring a
type-induced variable that is not intended to be an auto variable.

 
 These all works:
 
 void main()
 {
         auto f2 = cast(int)'\n';
         const f3 = cast(int)'\n';
         extern f5 = cast(int)'\n';
         static f8 = cast(int)'\n';
         synchronized f9 = cast(int)'\n';
 }
 
 see http://www.digitalmars.com/d/declaration.html#AutoDeclaration

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Norbert Nemec" <Norbert Nemec-online.de> wrote in message 
news:e596k7$2k4o$1 digitaldaemon.com...

 Maybe that common confusion could be lifted by introducing a new storage
 class (e.g. "local" or "var") indicating a "plain old local variable".
 This would be the default for any variable declared with a type and
 without storage class, but it would be useful in declaring a
 type-induced variable that is not intended to be an auto variable.

We already have it; it's called "auto"  ;)  That's exactly what auto means - 
a plain old variable, one which is not accessible once the scope ends.  It's 
already the default storage class for variables declared without one. 
That's why we use auto to indicate type inference for most variables, 
because they're plain old local variables, and that's the default storage 
class.

The problem is just when it comes to auto classes.  Either we come up with a 
new keyword for the behavior of auto classes, i.e. "raii":

raii Foo f = new Foo();

// Type inference
raii g = new Goo();

Or, something I was thinking - just reuse scope, as it's not used by itself 
anywhere.

scope Foo f = new Foo();

Though I'll admit, it's not as self-explanatory as "raii Foo". 

kris <foo bar.com> writes:

Jarrett Billingsley wrote:
 The problem is just when it comes to auto classes.  Either we come up with a 
 new keyword for the behavior of auto classes, i.e. "raii":
 
 raii Foo f = new Foo();
 
 // Type inference
 raii g = new Goo();
 
 Or, something I was thinking - just reuse scope, as it's not used by itself 
 anywhere.
 
 scope Foo f = new Foo();
 
 Though I'll admit, it's not as self-explanatory as "raii Foo". 



Are you kidding? RAII is about as self explanatory as a goat in a 
tumble-dryer. On the face of it, the use of 'scope' here seems like a 
great idea :)

Roald Ribe <rr.nospam nospam.teikom.no> writes:

kris wrote:
 Jarrett Billingsley wrote:
 The problem is just when it comes to auto classes.  Either we come up 
 with a new keyword for the behavior of auto classes, i.e. "raii":

 raii Foo f = new Foo();

 // Type inference
 raii g = new Goo();

 Or, something I was thinking - just reuse scope, as it's not used by 
 itself anywhere.

 scope Foo f = new Foo();

 Though I'll admit, it's not as self-explanatory as "raii Foo". 

 
 Are you kidding? RAII is about as self explanatory as a goat in a 
 tumble-dryer. On the face of it, the use of 'scope' here seems like a 
 great idea :)

I agree with you on raii. But I think local would be the optimal
keyword. local in scope, local on stack. local would be up to the
compiler to implement, depending on the environment, like register
in C. (meaning could even be tuned by a compiler switch).
scope is a good second IMO.

Roald

Norbert Nemec <Norbert Nemec-online.de> writes:

Jarrett Billingsley wrote:
 "Norbert Nemec" <Norbert Nemec-online.de> wrote in message 
 news:e596k7$2k4o$1 digitaldaemon.com...
 
 Maybe that common confusion could be lifted by introducing a new storage
 class (e.g. "local" or "var") indicating a "plain old local variable".
 This would be the default for any variable declared with a type and
 without storage class, but it would be useful in declaring a
 type-induced variable that is not intended to be an auto variable.

 
 We already have it; it's called "auto"  ;)  That's exactly what auto means - 
 a plain old variable, one which is not accessible once the scope ends.  It's 
 already the default storage class for variables declared without one. 
 That's why we use auto to indicate type inference for most variables, 
 because they're plain old local variables, and that's the default storage 
 class.

Sorry, but I disagree:
before type inference came along, "auto" already had a meaning. It said:
"This is *not* a plain old local variable but one that is deleted
automatically at end of scope." (In your terms, "auto" always meant RAII
in D)

 The problem is just when it comes to auto classes.  Either we come up with a 
 new keyword for the behavior of auto classes, i.e. "raii":
 
 raii Foo f = new Foo();
 
 // Type inference
 raii g = new Goo();

What you suggest here, is to change the meaning of "auto" and then
introduce a new keyword for what was "auto" before. At the moment,
"auto" means RAII. What we need is a keyword for non-RAII storage class.

Up to now, such a keyword was not necessary. With type inference, it
became necessary.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Norbert Nemec" <Norbert Nemec-online.de> wrote in message 
news:e5cl29$iat$1 digitaldaemon.com...

 Sorry, but I disagree:
 before type inference came along, "auto" already had a meaning. It said:
 "This is *not* a plain old local variable but one that is deleted
 automatically at end of scope." (In your terms, "auto" always meant RAII
 in D)

And before RAII classes came along, 'auto' already had a meaning then too!

'auto' only has special meaning for class references.  auto is also the 
default storage class for regular local variables, and is not a D-ism - it's 
from C.

What I'm proposing is that the class 'auto' is very different from the 
regular 'auto', and as such, they should have different keywords.  The class 
'auto' is more like a separate storage class, and if D gains the ability for 
RAII classes to have lifetimes dependent upon an owning class, that will be 
even more of a reason to have a separate storage class for RAII classes.

 What you suggest here, is to change the meaning of "auto" and then
 introduce a new keyword for what was "auto" before. At the moment,
 "auto" means RAII. What we need is a keyword for non-RAII storage class.

Currently, 'auto' is not consistent - it means one thing for 
non-class-references and another for class references.  What I'm suggesting 
is that "auto" go back to the way it was before RAII classes were 
introduced; that is, it's just a "plain old local variable which is not 
accessible after this scope exits."  With this new behavior, it will work as 
such:

auto int v = 0; // identical to just "int v = 0", just as it is now.
auto w = 5;  // same as it is now.
auto x = new X(); // Type inference; not a RAII class, like now.

And with the new 'raii' keyword (or equivalent):

raii Y y = new Y(); // Same as current "auto Y y = new Y();"
raii z = new Z(); // Type inference with RAII; currently impossible 

Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

Maybe something along the lines of one older proposal ?

// use 'auto' for type inference

auto k = Foo(2);          // raii; could be on the stack
auto l = new Foo(2);      // on the heap, gc'd

auto i = 1;               // raii in a way; on the stack
auto j = new int(1);      // on the heap, gc'd


That would mean one couldn't use static opCall, but it's usually used to 
fake ctors anyway...

/+
   To everyone: please don't suggest the 'raii' keyword... It's totally 
counter-intuitive in this case.
+/



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

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Sean Kelly <sean f4.ca> writes:

Hasan Aljudy wrote:
 Charlie wrote:
 2)  auto auto foo = new Class;  The current double meaning of auto 
 won't  allow for both a RAII and type-deduced variable declaration.  I 
 think every other language use's 'var' or similar ( var gets my vote, 

 storage class 'auto''.

 
 auto can mean many many things!!
 
 I prefer to get rid of auto all together.
 for automatic type inference ==> use 'var'

For what it's worth, the next iteration of C++ will use 'auto' to denote 
automatic type inference.

 for RAII, hmm, maybe use something like 'raii'
 


I still think the signifier for this is probably more appropriately 
associated with the instance than with the reference, since 'raii' isn't 
really a type qualifier.  I'd prefer:

auto foo = local Foo;

where 'auto' denotes automatic type inference and 'local' replaces 'new' 
to denote stack-based construction.  As far as 'local' is concerned, 
it's too bad 'new' is so generic.  Perhaps it should be 'new local' for 
scoped allocations?


Sean

Lionello Lunesu <lio lunesu.remove.com> writes:

 auto foo = local Foo;
 
 where 'auto' denotes automatic type inference and 'local' replaces 'new' 
 to denote stack-based construction.  As far as 'local' is concerned, 
 it's too bad 'new' is so generic.  Perhaps it should be 'new local' for 
 scoped allocations?

or using the already available new() syntax:

auto foo = new(local) Foo;

(Of course this will cause conflicts with any overridden 'new' in the class)

Anyway, I think I've read a post from Walter in which he seemed to like 
the implicit new/ctor syntax:

Foo f = new Foo(...);// heap
Foo f(...); //stack


L.