DAMN! I just refreshed before posting my response, and refreshed after posting and read this! Great idea!

Lionello.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsn62vgol23k2f5@nrage.netwin.co.nz...
> On Fri, 25 Mar 2005 11:55:41 +0100, Knud Sørensen <12tkvvb02@sneakemail.com> wrote:
>> When coming from C++ it seems strange
>> that you should write the class name twice to get an element.
>> C++: MyClassName aElement(...);
>> D:   MyClassName aElement= new MyClassName(...);
>>
>> That is almost twice as much typing to do the same thing, and that is every time you need an element of a class.
>
> If anything, I would like this idea better..
>
> MyClassName a;       //a is null
> MyClassName a();     //same as MyClassName a = new MyClassName();
> MyClassName a(1,2);  //same as MyClassName a = new MyClassName(1,2);
> MyClassName a = new MyClassName(1,2,3);  //obvious :)
>
> Though, and here's the kicker, the a() example looks like a class created on the stack, right? as in C++, and it's not.
>
> Regan

"Knud Sørensen" <12tkvvb02@sneakemail.com> wrote in message news:pan.2005.03.25.10.55.40.584375@sneakemail.com...
>
>> The =null makes more sense than the =!new.
>> How did it turn into !new on the eigenpoll? oh well.
>
> Apparently someone posted it with !new.
> The question is how long it will take
> for someone to post a new suggestion with null.
>
> But I can see why it is popular.
>
> When coming from C++ it seems strange
> that you should write the class name twice to get an element.
> C++: MyClassName aElement(...);
> D:   MyClassName aElement= new MyClassName(...);

This argument doesn't hold: you can't say it's to make things simpler for C++ programmers and then give them completely different behaviour. In C++, that syntax creates an object on the stack; in the proposal for D, it still creates an object on the heap.

From what I've seen of this proposal and the follow-up threads, it's actually complicating matters and would require a lot of special-casing.

>
> That is almost twice as much typing to do the same thing, and that is every time you need an element of a class.
>
> To go easy on exiting code the compiler could be updated in stages.
>
> 1) Warn for implicit null code like
> MyClassName nullElement;
>
> 2) Disallow implicit null and enforce
> MyClassName nullElement = null;
> This will force all existing code to be updated.
>
> 3) After a while change
> MyClassName aElement;
> to implicit mean
> MyClassName aElement = new MyClassName;
>
>> But even with =null I would be surprised if Walter goes
>> for it. The proposal doesn't feel right to me for two reasons: 1) an
>> expensive operation like "new" shouldn't be implicit,
>
> Not even if you need it anyway 99.99% of the time ?
>
>> and 2) it would mean
>> the code
>> Foo a;
>> a = ...;
>> is different than
>> Foo a = ...;
>> Even though C++ distinguishes between initialization and assignment I
>> don't
>> D should go down that road.
>
>
> 

I like this idea!
I have added it as "short syntax for new" to the wish list at:

http://all-technology.com/eigenpolls/dwishlist/


> MyClassName a;       //a is null
> MyClassName a();     //same as MyClassName a = new MyClassName();
> MyClassName a(1,2);  //same as MyClassName a = new MyClassName(1,2);
> MyClassName a = new MyClassName(1,2,3);  //obvious :)
> 
> Though, and here's the kicker, the a() example looks like a class created on the stack, right? as in C++, and it's not.
> 
> Regan

On Thu, 24 Mar 2005 19:01:10 -0500, Ben Hinkle wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:1hyzck675ctcf$.14kdoa1p26fdc$.dlg@40tude.net...
>> On Thu, 24 Mar 2005 17:58:31 -0500, Ben Hinkle wrote:
>>
>>> <12tkvvb02@sneakemail.com> wrote in message news:d1uve0$2ca$1@digitaldaemon.com...
>>>> Hi
>>>>
>>>> This is the monthly status for the unofficial d wish list: http://all-technology.com/eigenpolls/dwishlist/
>>>>
>>>> Right now the wish list looks like this:
>>>>
>>>> 0.565  5  Auto new-ing of classes
>>> I'd be very surprised if Walter changes the language to do that. The
>>> current
>>> system is much better.
>>
>> I submitted this one. There is further discussion at ...
>>
>> http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/AutoNewingOfClasses
> 
> The =null makes more sense than the =!new. How did it turn into !new on the eigenpoll? oh well.

It was the other way round, actually. I first put it into the poll with the "=!new" and later it was pointed out to me that this was not clever. I agree and when I wrote it up in the wiki I changed it to the "=null" syntax.

I think my original idea has taken off into directions I didn't intend it to go, but that's normal I guess. My original feeling was just to switch the default behaviour such that the more common usage would be reflected in simpler syntax.

We currently do ...
  struct Sct { . . .}
  class CLS {  . . .}
  int   a;
  int[] b;
  Sct   c;
  Cls   d = new Cls;

to make each of the variables usable, and I see that the requirement to use 'new' is an anomaly. So all I was suggesting was that seeing the form "CLASS a = new CLASS;" is such a common idiom, that a simpler syntax would be appreciated.

It has nothing to do with C++ or Java behaviour as I don't use those languages, and really couldn't care less what they do or don't do. I'm trying to make D more coder/reader friendly.

I first fell foul of this requirement when I had struct being used in me application, and later I changed it to a class; then all of a suddenly I had Access Violations all over the place :-(

I still forget to add the "= new <whatever>;" occasionally and trip up during testing.

>But even with =null I would be surprised if Walter goes
> for it.

Me too, but not for the reasons you speak of. I guess it means work for him to change things and he is already too busy. ;-)

> The proposal doesn't feel right to me for two reasons: 1) an expensive operation like "new" shouldn't be implicit,

real[50000] x;

Is also implicit (the is no 'new' involved) but every one knows what's
going on.

The idiom 'CLASS x = new CLASS;' is very common. So why not make coding easier to write and read.

> and 2) it would mean
> the code
> Foo a;
> a = ...;
> is different than
> Foo a = ...;
> 
> Even though C++ distinguishes between initialization and assignment I don't D should go down that road.

How is that different from ...

  char[] S;   // Initialize the array
  S =  . . .; // Assign the array.

If one knows the rule that 'Foo a;' invokes the default constructor, and one doesn't want that, then code it as 'Foo a=null;'. I still suspect that this is a minority of cases.

Even though I concede that we are never likely to see Walter change this, I can still voice an opinion, no?

-- 
Derek Parnell
Melbourne, Australia
26/03/2005 4:48:08 PM

>> The =null makes more sense than the =!new. How did it turn into !new on
>> the
>> eigenpoll? oh well.
>
> It was the other way round, actually. I first put it into the poll with
> the
> "=!new" and later it was pointed out to me that this was not clever. I
> agree and when I wrote it up in the wiki I changed it to the "=null"
> syntax.

oh, ok.

> I think my original idea has taken off into directions I didn't intend it
> to go, but that's normal I guess. My original feeling was just to switch
> the default behaviour such that the more common usage would be reflected
> in
> simpler syntax.
>
> We currently do ...
>  struct Sct { . . .}
>  class CLS {  . . .}
>  int   a;
>  int[] b;
>  Sct   c;
>  Cls   d = new Cls;
>
> to make each of the variables usable, and I see that the requirement to
> use
> 'new' is an anomaly. So all I was suggesting was that seeing the form
> "CLASS a = new CLASS;" is such a common idiom, that a simpler syntax would
> be appreciated.

The anomaly is that classes must be new'ed since they aways have reference semantics while the other types have value semantics so to get reference semantics you have to new them. So having the new for Cls makes it consistent with newing the other types.

> It has nothing to do with C++ or Java behaviour as I don't use those languages, and really couldn't care less what they do or don't do. I'm trying to make D more coder/reader friendly.

a good goal

> I first fell foul of this requirement when I had struct being used in me application, and later I changed it to a class; then all of a suddenly I had Access Violations all over the place :-(

That's a good thing that it crashed since reference semantics is vastly different than value semantics and implicitly newing them would have introduced bugs that would probably be harder to track down than a crash.

> I still forget to add the "= new <whatever>;" occasionally and trip up during testing.

ok

>> The proposal doesn't feel right to me for two reasons: 1) an expensive operation like "new" shouldn't be implicit,
>
> real[50000] x;
>
> Is also implicit (the is no 'new' involved) but every one knows what's
> going on.

True but initialization it consistent across all types.

> The idiom 'CLASS x = new CLASS;' is very common. So why not make coding easier to write and read.

True it is common.

>> and 2) it would mean
>> the code
>> Foo a;
>> a = ...;
>> is different than
>> Foo a = ...;
>>
>> Even though C++ distinguishes between initialization and assignment I
>> don't
>> D should go down that road.
>
> How is that different from ...
>
>  char[] S;   // Initialize the array
>  S =  . . .; // Assign the array.

I don't see the connection with dynamic arrays. Declaring a dynamic array does not allocate any memory for it.

> Even though I concede that we are never likely to see Walter change this,
> I
> can still voice an opinion, no?

absolutely. I don't mean to sound harsh. I was just voicing my concerns about a proposal that I saw at the top of the eigenpoll. I'm now wondering just how this eigenpoll works since every post looks like a random bunch of data.

On Sat, 26 Mar 2005 17:21:25 +1100, Derek Parnell <derek@psych.ward> wrote:
> On Thu, 24 Mar 2005 19:01:10 -0500, Ben Hinkle wrote:
>
>> "Derek Parnell" <derek@psych.ward> wrote in message
>> news:1hyzck675ctcf$.14kdoa1p26fdc$.dlg@40tude.net...
>>> On Thu, 24 Mar 2005 17:58:31 -0500, Ben Hinkle wrote:
>>>
>>>> <12tkvvb02@sneakemail.com> wrote in message
>>>> news:d1uve0$2ca$1@digitaldaemon.com...
>>>>> Hi
>>>>>
>>>>> This is the monthly status for the unofficial d wish list:
>>>>> http://all-technology.com/eigenpolls/dwishlist/
>>>>>
>>>>> Right now the wish list looks like this:
>>>>>
>>>>> 0.565  5  Auto new-ing of classes
>>>> I'd be very surprised if Walter changes the language to do that. The
>>>> current
>>>> system is much better.
>>>
>>> I submitted this one. There is further discussion at ...
>>>
>>> http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/AutoNewingOfClasses
>>
>> The =null makes more sense than the =!new. How did it turn into !new on the
>> eigenpoll? oh well.
>
> It was the other way round, actually. I first put it into the poll with the
> "=!new" and later it was pointed out to me that this was not clever. I
> agree and when I wrote it up in the wiki I changed it to the "=null"
> syntax.
>
> I think my original idea has taken off into directions I didn't intend it
> to go, but that's normal I guess. My original feeling was just to switch
> the default behaviour such that the more common usage would be reflected in
> simpler syntax.
>
> We currently do ...
>   struct Sct { . . .}
>   class CLS {  . . .}
>   int   a;
>   int[] b;
>   Sct   c;
>   Cls   d = new Cls;
>
> to make each of the variables usable, and I see that the requirement to use 'new' is an anomaly.

I think perhaps if you look at it from a different view/perspective...

For example:

  Cls d;

Allocates a "reference" on the "stack".

  int[] b;

Allocates a "reference" on the "stack".

  Cls d = new Cls();

Allocates a "reference" on the "stack" then allocates a "Cls" on the "heap".

  int[] b = new int[100];

Allocates a "reference" on the "stack" then allocates a block of memory on the "heap".

'int' and structs are the same as references, they are allocated on the "stack".

So, "new" indicates "heap" allocation. Values assigned to references generally(always?) involve "heap" memory i.e. array contents, and classes.

> So all I was suggesting was that seeing the form
> "CLASS a = new CLASS;" is such a common idiom, that a simpler syntax would
> be appreciated.

This I can agree with, at least a little, I think perhaps:

Cls d();
Cls e(1,2,3);

could be shorthand for:

Cls d = new Cls();
Cls e = new Cls(1,2,3);

but, it does make it harder to search for heap allocations (no 'new' to look for) and it does make it less obvious they are going on. So I can understand reservation about adding this sort of shorthand.

> It has nothing to do with C++ or Java behaviour as I don't use those
> languages, and really couldn't care less what they do or don't do. I'm
> trying to make D more coder/reader friendly.

An admirable goal.

> I first fell foul of this requirement when I had struct being used in me
> application, and later I changed it to a class; then all of a suddenly I
> had Access Violations all over the place :-(

Yeah.. I've been bitten by the difference between struct and class, tho my experience was WRT to in/out/inout variables. I think the difference is a good this, why have two shovels when I can have a shovel and a fork. Different tools for different tasks, remember how to use your tools.

>> The proposal doesn't feel right to me for two reasons: 1) an
>> expensive operation like "new" shouldn't be implicit,
>
> real[50000] x;
>
> Is also implicit (the is no 'new' involved) but every one knows what's
> going on.

This is a static array.. there is no requirement that the memory be allocated on the "heap" (IIRC and I may not) so it could be "stack" memory, and/or static ROM (in the case of a static array). If the memory is on the heap then you can say, "x" is a reference on the "stack" referencing "heap" memory of size "50000".

>> and 2) it would mean
>> the code
>> Foo a;
>> a = ...;
>> is different than
>> Foo a = ...;
>>
>> Even though C++ distinguishes between initialization and assignment I don't
>> D should go down that road.
>
> How is that different from ...
>
>   char[] S;   // Initialize the array
>   S =  . . .; // Assign the array.

It's not.

"char[] S;" - allocates a "reference" on the "stack".
"S = " - assigns something to that reference. (generally "heap" memory")

> If one knows the rule that 'Foo a;' invokes the default constructor, and
> one doesn't want that, then code it as 'Foo a=null;'. I still suspect that
> this is a minority of cases.

I can't say whether wanting "null" or wanting "not null" is more common, I suspect it's a matter of style.

> Even though I concede that we are never likely to see Walter change this, I
> can still voice an opinion, no?

Yep. Keep em coming.

Regan

Derek Parnell wrote:

> It has nothing to do with C++ or Java behaviour as I don't use those
> languages, and really couldn't care less what they do or don't do. I'm
> trying to make D more coder/reader friendly.

Java has the same behaviour as D, in that Object variables are just
references and different from primitive types (they are also similar)

People have been tripping up on "NullPointerException" (i.e. the Java
equivalent of the Access Violation error that D has) for a long time...


There are extensions to Java that eliminates both NullPointerException
and ClassCastException, such as the "Nice" programming language...

(note that the ClassCastException in D becomes a "NullPointerException"
instead, since a cast() that can't be done simply returns null instead)

http://nice.sourceforge.net/safety.html:
> In current imperative languages, references (or pointers) can hold a
> special value meaning "reference to nothing". This value is called null
> in Java, NULL in C and C++. At run time, however, dereferencing this
> value results to a runtime error (NullPointerException) or a run time
> crash (bus error, segmentation fault, protection fault, ...).

I'm not sure I like their "solution" to it, but they do offer one...
(it's detailed on the page that is reference by the hyperlink above)

Another one is at: http://c2.com/cgi/wiki?NullConsideredHarmful
(there's a lot of good stuff at that page, and the ones it links to)


So what C++ and Java does *can* be relevant to the discussion, not just
for compatibility, but to see how they address the very same problem ?

In the Java case, it doesn't have either pointers nor structures, which
makes it easier to avoid mixing value types and reference types up...

The plot in D thickens, if you e.g. compare the difference between null objects and null arrays, for instance if you try to print one Object and one char[] which both have a value of "null". Very different results...
(similar to trying to use '==' to compare objects vs. comparing strings)

--anders

On Sun, 27 Mar 2005 00:29:39 +0100, Anders F Björklund wrote:

> Derek Parnell wrote:
> 
>> It has nothing to do with C++ or Java behaviour as I don't use those languages, and really couldn't care less what they do or don't do. I'm trying to make D more coder/reader friendly.
> 
> Java has the same behaviour as D, in that Object variables are just references and different from primitive types (they are also similar)

[snip]

> So what C++ and Java does *can* be relevant to the discussion, not just for compatibility, but to see how they address the very same problem ?

[snip]

To me, it doesn't matter what <YourFavouriteProgrammingLangauge> does, and yes it is interesting to see how other languages deal with that problem. But the problem I'm having is explain what I see that problem is ;-)

Here's another stab at it ...

A common idiom (invoking the default constructor) has significantly more keystrokes than the less common idiom (initializing the class reference to null). Why can we change that situation, such that the common idiom uses less keystrokes but still remains readable?

The issue I'm highlighting is not about reference types vs heap types, C++ vs Java, initialization vs assignment, etc... It has to do with making program source code easier to write and easier to read. I am not dogmatically saying *my* suggestion *must* be implemented. My suggestion is just a starting point for other, probably better, ideas.

Anyhow, I give up. You guys have beaten me into silence on this issue.

-- 
Derek Parnell
Melbourne, Australia
27/03/2005 10:20:10 AM

> Anyhow, I give up. You guys have beaten me into silence on this issue.

geez, now you're making me feel bad for saying anything negative about your proposal. :P oh well. I'm sorry you feel that way. I feel like we all have understood each other's point of view and disagree on the conclusions - which happens all the time in situations where the conclusions are subjective. I'm probalby reading too much into that closing, but I hope you don't feel beaten up.

On Sun, 27 Mar 2005 10:30:52 +1000, Derek Parnell wrote:

> 
> Anyhow, I give up. You guys have beaten me into silence on this issue.

That why I made the wish list. When someone make a suggestion only
people how disagree reply on it.
But your suggestion is still doing well on the wish list,
and the similar "short syntax for new" is coming along fine.

Knud