Walter Bright wrote:
> A couple of oft-requested features.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 

Would the new auto declaration permit a "mode" where ALL declarations are implicitly auto?

e.g.

<code>

x = 1; 				// x is int and has value 1
x = 2; 				// x is assigned 1
x = 1u; 		 	// Compile Error?
x = new AnotherObject(); 	// Compile Error: x is int

o1 = new MyObject(1);		// o1 is MyObject
o2 = new MyObject(2);		// o2 is MyObject
o1 = o2;			// okay
o1 = new AnotherObject();	// Compile Error: o1 is MyObject
ao = new AnotherObject();	// okay
o2 = ao;			// Compile Error: o2 is MyObject

</code>

What could be broken in this? Well, obviously there is the issue that you cant declare a new local variable with the same name as a variable in an outer scope. Then there case where conversions are possible is another area. Another is the cases where the complier cant determine the type of the rvalue. I dont know if there are any cases of this though.

Another question is is this desirable syntax? I think if you are going to use the auto type declaration, then yes it is, saves 4 keystrokes per declaration.

Kyle Furlong wrote:
> Walter Bright wrote:
> 
>> A couple of oft-requested features.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>>
>>
> 
> Would the new auto declaration permit a "mode" where ALL declarations are implicitly auto?
> 
> e.g.
> 
> <code>
> 
> x = 1;                 // x is int and has value 1
> x = 2;                 // x is assigned 1

This line should read:

x = 2;                 // x is assigned 2

> x = 1u;              // Compile Error?
> x = new AnotherObject();     // Compile Error: x is int
> 
> o1 = new MyObject(1);        // o1 is MyObject
> o2 = new MyObject(2);        // o2 is MyObject
> o1 = o2;            // okay
> o1 = new AnotherObject();    // Compile Error: o1 is MyObject
> ao = new AnotherObject();    // okay
> o2 = ao;            // Compile Error: o2 is MyObject
> 
> </code>
> 
> What could be broken in this? Well, obviously there is the issue that you cant declare a new local variable with the same name as a variable in an outer scope. Then there case where conversions are possible is another area. Another is the cases where the complier cant determine the type of the rvalue. I dont know if there are any cases of this though.
> 
> Another question is is this desirable syntax? I think if you are going to use the auto type declaration, then yes it is, saves 4 keystrokes per declaration.

In article <opszbqbmzg23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 27 Oct 2005 21:30:12 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
>> In article <opszbo89dr23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>
>>> On Thu, 27 Oct 2005 19:48:41 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
>>>>
>>>> Interesting.  So the variable would be declared the same either way?
>>>> Would such
>>>> a design support returning classes by value?  ie.
>>>>
>>>> MyClass getInstance() {
>>>> MyClass c = MyClass();
>>>> return c;
>>>> }
>>>>
>>>> From what you're saying, this sounds like it would produce undefined behavior.
>>>
>>> Why can't this simply be detected at compile time?
>>
>> I think it could be for simple cases, but I'm not sure the compiler could catch all such errors.  Though perhaps partial detection is sufficient...
>
>Why not? Surely you just flag the actual instance as stack based and then error whenever someone returns a reference to a stack based instance?
>
>Regan

I think you're right - this should be do-able at compile time as long as the assignments are direct and not through pointers to references, etc. And even then the semantic optimizer in the reference compiler will remove cases like this (this 'optimizer' is run no matter which compiler flags are used):

MyClass c1 = new MyClass;
MyClass c2 = *&c1; // optimized to c2 = c1;

In article <djrbo0$lkk$1@digitaldaemon.com>, Ivan Senji says...
>
>Sean Kelly wrote:
>> In article <djr50f$4pr$3@digitaldaemon.com>, Walter Bright says...
>> 
>>>The statement will remain true, and that's because class declarations are only for *references* to a class, not instances. The auto reference will always go away at the end of the scope. Whether the instance does or not depends on if it is on the class or the stack. The way the initializer is written determines if it is a stack or a heap instance.
>> 
>> 
>> Interesting.  So the variable would be declared the same either way?  Would such a design support returning classes by value?  ie.
>> 
>> MyClass getInstance() {
>> MyClass c = MyClass();
>> return c;
>> }
>> 
>> From what you're saying, this sounds like it would produce undefined behavior.
>
>As it would in C++, at the end of scope c is dead.
>

Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit) and that temporary copy is returned; so it really isn't undefined behaviour although it can hide bugs that seem like it <g>

I think the prev. poster was just asking (as I did earlier with an example) if Walter has some magic that would allow this? Like how stack allocated D structs are returned by value (shallow copy of heap members), which D can usually get away with because of the GC.

>> And in large function calls, this could be an easy mistake to make.  Why omit
>
>Indeed.
>
>> the need for pointer semantics for heap-based classes?  I'd think it would offer a degree of checking that the handle-based syntax doesn't:
>> 
>> MyClass* getInstance() {
>> MyClass c = MyClass();
>> return c; // error: cannot convert MyClass to MyClass*
>> }
>> 
>
>Yuck.
>With stack based class objects we are getting big bunch of problems with
>returning destructed objects. Is it really a good idea to have
>stack-based classes? We have lived without them for a long time in D.
>And although i can see that they have some advantages (like speed) but
>it looks to me they bring big problems to the language.
>
>> 
>> Sean
>> 
>> 

In article <djrt8q$2o2o$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Sean Kelly" <sean@f4.ca> wrote in message news:djraup$jeb$1@digitaldaemon.com...
>> In article <djr50f$4pr$3@digitaldaemon.com>, Walter Bright says...
>> >
>> >The statement will remain true, and that's because class declarations are only for *references* to a class, not instances. The auto reference will always go away at the end of the scope. Whether the instance does or not depends on if it is on the class or the stack. The way the initializer is written determines if it is a stack or a heap instance.
>>
>> Interesting.  So the variable would be declared the same either way?
>Would such
>> a design support returning classes by value?  ie.
>>
>> MyClass getInstance() {
>> MyClass c = MyClass();
>> return c;
>> }
>
>Returning references to stack variables is wrong, wrong, wrong <g>.
>

What happens with structs now? They are copied by value, but are not deep copied. In D this is usually fine w/o big problems because of the GC - as long as the programmer remembers that pointers and ref. types will refer to the same chunk of memory unless reassigned:

void main()
{
S s = foo();
printf("%d\n",s.c.i);
}

struct S { C c; }
class C { int i; }

S foo()
{
S s;
s.c = new C;
s.c.i = 10;
return s;
}

So, for stack alloc. classes (excluding RAII), couldn't an implicit shallow copy be made into a temporary returned on the stack, and then the reference to that assigned in the new scope? From there the semantics for stack allocated class objects with pointer and ref. members would be consistent with returning structs by value.

>> From what you're saying, this sounds like it would produce undefined
>behavior.
>> And in large function calls, this could be an easy mistake to make.  Why
>omit
>> the need for pointer semantics for heap-based classes?  I'd think it would
>offer
>> a degree of checking that the handle-based syntax doesn't:
>>
>> MyClass* getInstance() {
>> MyClass c = MyClass();
>> return c; // error: cannot convert MyClass to MyClass*
>> }
>
>It's not an improvement, the same errors are possible. Those errors are just as possible in C++, too.
>
>

Dave wrote:
> In article <djrbo0$lkk$1@digitaldaemon.com>, Ivan Senji says...
>>As it would in C++, at the end of scope c is dead.
>>
> 
> 
> Yes, 'c' is dead, but before that the copy ctor is called (implicit or explicit)
> and that temporary copy is returned; so it really isn't undefined behaviour
> although it can hide bugs that seem like it <g>
> 

Copy ctor? D doesn't hava a copy ctor. c is a reference to a location on the stack, and when you exit the method and the objects is destroyed you really shouldn't be using that memory location.

Can hide bugs? It is a bug.

> I think the prev. poster was just asking (as I did earlier with an example) if
> Walter has some magic that would allow this? Like how stack allocated D structs
> are returned by value (shallow copy of heap members), which D can usually get
> away with because of the GC.

Only Walter knows. But structs are very different from classes.

> ...

Kyle Furlong wrote:
> Walter Bright wrote:
> 
>> A couple of oft-requested features.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>>
>>
> 
> Would the new auto declaration permit a "mode" where ALL declarations are implicitly auto?
> 
> e.g.
> 
> <code>
> 
> x = 1;                 // x is int and has value 1
> x = 2;                 // x is assigned 1
> x = 1u;              // Compile Error?
> x = new AnotherObject();     // Compile Error: x is int
> 
> o1 = new MyObject(1);        // o1 is MyObject
> o2 = new MyObject(2);        // o2 is MyObject
> o1 = o2;            // okay
> o1 = new AnotherObject();    // Compile Error: o1 is MyObject
> ao = new AnotherObject();    // okay
> o2 = ao;            // Compile Error: o2 is MyObject
> 
> </code>
> 
> What could be broken in this? Well, obviously there is the issue that you cant declare a new local variable with the same name as a variable in an outer scope. Then there case where conversions are possible is another area. Another is the cases where the complier cant determine the type of the rvalue. I dont know if there are any cases of this though.
> 
> Another question is is this desirable syntax? I think if you are going to use the auto type declaration, then yes it is, saves 4 keystrokes per declaration.

Syntax is great with auto because it simplifies things alot, but for x=1; to be a declaration would be a big mistake, i never liked those languages, things like that cause bugs that are really hard to find if you for example misspell something, or if you later need to find the places in code where you declare new objects it is imposible.

Dave wrote:
> So, for stack alloc. classes (excluding RAII), couldn't an ...
Walter has said this here before: stack allocated classes/objects and RAII classes/objects are *the same*. There is no stack allocated classes/objects that are not RAII.

> In article <djrt8q$2o2o$1@digitaldaemon.com>, Walter Bright says...
>>
>>"Sean Kelly" <sean@f4.ca> wrote in message
>>Would such
>>
>>>a design support returning classes by value?  ie.
>>>
>>>MyClass getInstance() {
>>>MyClass c = MyClass();
>>>return c;
>>>}
>>
>>Returning references to stack variables is wrong, wrong, wrong <g>.
>>
"Would such a design support returning classes by value?"
Why did everyone suddenly started talking about implementind value semantics for classes? It has nothing to do with the current design/issue (which is RAII and auto-type). Just because the new RAII proposal has a syntax similiar to C++'s value objects, it doesn't mean they are anywhere near the same.


> What happens with structs now? They are copied by value, but are not deep
> copied. ...
What follows is a reply to also some other comments in others posts:
Structs have value semantics because they are structs, *not because* they are stack allocated. Thus just because we have stack allocated objects (RAII) doesn't mean they should have value semantics as well!
D's objects follow a reference model (all of them), and any discussion regarding that, is off-topic for this thread.

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

Ivan Senji wrote:
> Bruno Medeiros wrote:
> 
>>
>> auto c = new C();   // c is not RAII , is auto-typed
>> auto C d = new C(); // c is RAII, is not auto-typed
>>
> 
> Shouldn't it be:
> 
> type c = new type(args); //type not infered, no RAII
> auto c = new type(args); //type infered, no RAII
> type c = type(args);     //type not infered, RAII
> auto c = type(args);     //type infered, RAII
> 
> At least this is what i figured out it should be, so:
> auto means type is infered, no new means RAII.
> 

No it shouldn't be. I said before (here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce/1771 ) that I was talking about the current DMD.137 situation in that post, not Walter's new proposal.


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

Walter Bright wrote:
> A couple of oft-requested features.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 

Can we have a new warning for use of potentially uninitialized variable?  I know this might cause problems with current code relying on D's default initialization values.

Anyway, I have a mathematical model which makes exclusive use of the double floating-point type, and doubles are initialized to NaN in D by default.  Consequently, propogating NaNs through the calculation makes it hard to track down where the first NaN came from - hence, which variable in particular was forgotten to be initialized.

There are a lot of variables in this model, and debugging is not easy since it is running under Excel (from VBA) as an external Win32 DLL, so no printf tricks will track the guy down unfortunately.

Anyway, I think my point still stands.  Use of uninitialized variable warning, please?  Or perhaps a way to trap usage of a NaN in a calculation and break into the debugger - THAT would make debugging MUCH faster, i.e. use SNANs instead of QNANs (signaling/noisy vs. quiet).