www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A few inconsistentcies left

reply 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
May 25 2006
next sibling parent 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;
May 25 2006
prev sibling parent reply 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'
May 25 2006
next sibling parent reply 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
May 25 2006
parent reply 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
May 27 2006
next sibling parent reply "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".
May 27 2006
next sibling parent reply 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 :)
May 27 2006
parent 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
May 27 2006
prev sibling parent reply 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.
May 28 2006
parent "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
May 28 2006
prev sibling parent 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 +/
May 28 2006
prev sibling parent reply 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
May 25 2006
parent 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.
May 26 2006