Don has a good point: changing to "var" would cause conflict with existing variable-names.

Chad et. al. also have a good point about the conflict regarding static opCall() (via the lack of a "new" keyword). I suspect many people find the use of "new" to be indicative of allocation, and breaking this consistency may have a detrimental effect? Further, it was noted that a missing "new" can only be used at the instantiation site -- not at the class decl -- thus, D would be losing an existing feature.

I suspect you could count the current number of raii-class uses on a few hands, whereas the use of "auto" for implied-type is pretty darned popular -- and rightly so, since it's really very, very useful. Changing the raii style to use a different keyword, whilst retaining implied-type "auto" would be an almost imperceptible change?

Thus, it would appear to make sense to retain "auto" for implied-type, and introduce something *else* for automatic cleanup at end-of-scope (and also as a class attribute). how about reusing the "scope" keyword?

void main()
{
  auto i = 10;
  auto foo = new Foo;
  auto scope bar = new Bar;
  auto scope wumpus = new Wumpus;
}

class Foo {}

class Bar {}

scope class Wumpus {}

kris schrieb:
> Don has a good point: changing to "var" would cause conflict with existing variable-names.

I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier. I also strongly believe that no one should. It's the implication of a maintenance nightmare.
I don't intend to insult Don in any way but it's a horrible practice IMNSHO that should not be preserved.

So let's not focus on some odd minority but rather on the wide use of "var" in the context of type inference and dynamic typing.

Also I don't think that it's a good habit to be looking at how C++ does something unless one is looking for a bad example. My main reason for interest in D is because personally I'm fed up with C++ and consider it an abomination and a major PITA.

Just my 0.02 EUROs,

Nils

Nils Hensel wrote:
> kris schrieb:
> 
>> Don has a good point: changing to "var" would cause conflict with existing variable-names.
> 
> 
> I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier. I also strongly believe that no one should. It's the implication of a maintenance nightmare.
> I don't intend to insult Don in any way but it's a horrible practice IMNSHO that should not be preserved.
> 
> So let's not focus on some odd minority but rather on the wide use of "var" in the context of type inference and dynamic typing.
> 
> Also I don't think that it's a good habit to be looking at how C++ does something unless one is looking for a bad example. My main reason for interest in D is because personally I'm fed up with C++ and consider it an abomination and a major PITA.
> 
> Just my 0.02 EUROs,
> 
> Nils


Well, it would have notable impact on existing code to change auto to var. They're at least equally clear in my view, so it would come down to a question of impact upon existing code.

What's more important is the clarification of what "auto" means. Right now, it's somewhat confused (with raii). If we instead use "scope" to indicate raii, that confusion just goes away.

Besides, "scope" is a fine attribute for things that are "scoped" :)

On Tue, 25 Jul 2006 20:14:52 +0200, Nils Hensel <nils.hensel@web.de> wrote:
> kris schrieb:
>> Don has a good point: changing to "var" would cause conflict with existing variable-names.
>
> I'm sorry but I don't believe there are many programmers out there actually using something as undescriptive as "var" as a regular identifier. I also strongly believe that no one should. It's the implication of a maintenance nightmare.
> I don't intend to insult Don in any way but it's a horrible practice IMNSHO that should not be preserved.

I don't use "var" specifically but I have been known to use tmp, x, y, i, j, p, s, n, .. for all my temporary and/or meaningless variables. They typically have a short scope life and I can't see a problem with this practice.

> So let's not focus on some odd minority but rather on the wide use of "var" in the context of type inference and dynamic typing.

I think Kris's point is that of the two choices 'var' and 'auto' the latter is less likely to annoy someone by colliding with existing user variables. The point is valid so long as the group of 'var' users is bigger than the group of 'auto' users, even if both groups are small.

> Also I don't think that it's a good habit to be looking at how C++ does something unless one is looking for a bad example. My main reason for interest in D is because personally I'm fed up with C++ and consider it an abomination and a major PITA.

C++ may be an abomination but it does have 'market' dominance. You have to ask 'why'. You should learn from your 'enemies' ;)

Regan

On Tue, 25 Jul 2006 10:17:13 -0700, kris <foo@bar.com> wrote:
> Don has a good point: changing to "var" would cause conflict with existing variable-names.
>
> Chad et. al. also have a good point about the conflict regarding static opCall() (via the lack of a "new" keyword). I suspect many people find the use of "new" to be indicative of allocation, and breaking this consistency may have a detrimental effect? Further, it was noted that a missing "new" can only be used at the instantiation site -- not at the class decl -- thus, D would be losing an existing feature.
>
> I suspect you could count the current number of raii-class uses on a few hands, whereas the use of "auto" for implied-type is pretty darned popular -- and rightly so, since it's really very, very useful. Changing the raii style to use a different keyword, whilst retaining implied-type "auto" would be an almost imperceptible change?
>
> Thus, it would appear to make sense to retain "auto" for implied-type, and introduce something *else* for automatic cleanup at end-of-scope (and also as a class attribute). how about reusing the "scope" keyword?
>
> void main()
> {
>    auto i = 10;
>    auto foo = new Foo;
>    auto scope bar = new Bar;
>    auto scope wumpus = new Wumpus;
> }
>
> class Foo {}
>
> class Bar {}
>
> scope class Wumpus {}

I say lets keep 'auto' for auto type inference (for the reasons you and Don mention)

I like the use of scope at class decl. But, I prefer the no keyword approach at instantiation. So, allow me to suggest this as a 3rd option.

- 'scope' at class decl.
- no keyword at instatiation.

Reasoning:

'new' implies heap allocation to me. It would be beneficial to allow the compiler to allocate an RAII type in any way it wants, perhaps stack allocating it. Removing 'new' removes the implied heap allocation allowing the compiler to allocate however it likes.

I don't see the utility in static opCall, I say abolish/remove it. Non-static opCall on the other hand can be quite useful.

Regan

Regan Heath wrote:
> 
> 
> I say lets keep 'auto' for auto type inference (for the reasons you and  Don mention)
> 
> I like the use of scope at class decl. But, I prefer the no keyword  approach at instantiation. So, allow me to suggest this as a 3rd option.
> 
> - 'scope' at class decl.
> - no keyword at instatiation.
> 
> Reasoning:
> 
> 'new' implies heap allocation to me. It would be beneficial to allow the  compiler to allocate an RAII type in any way it wants, perhaps stack  allocating it. Removing 'new' removes the implied heap allocation allowing  the compiler to allocate however it likes.
> 

I disagree.

If you want the compiler to be able to optimize by using stack allocation instead of heap allocation, then let it do that with the new keyword.  I'm assuming the program's behaviour would be the same in either case, so it wouldn't matter to me.

If you want stack allocation then how about
scope A a = A();

It keeps the concepts of scope and allocation seperate.  Scope is not allocation.  For instance, if the function is inlined then something allocated on the stack should live longer than the scope of the function.  The only exceptions I can think of are if the compiler forbids inlining of such functions (possibly inefficient) or there is a scope guarantee, in which case you want scope AND stack alloc.  Or maybe I just don't understand inlining (hope not!).

> I don't see the utility in static opCall, I say abolish/remove it.  Non-static opCall on the other hand can be quite useful.
> 
> Regan

Please don't abolish/remove it.  At least not until you have convinced me that it is totally useless.  I really don't like the idea of dropping a language feature just for the sake of having a particular syntax that, IMO, is not intuitive.  As I said in the 1.0 thread, A a = A(); looks to me like anything but a scoped instanciation; I'd rather have a keyword (like scope) to indicate what it is in an explicit way.

From my previous post about this:
> I like being able to use types as functions.
> Here's one example where I do something similar to what you'd use nested functions for, but better - my forward referencing woes go away.
> 
> class F
> {
>     int result;
>     int tempVar1;
> 
>     static int opCall( int x )
>     {
>         F f = new F(x);
>         int result = f.result;
>         delete f;
>         return result;
>     }
> 
>     this( int x )
>     {
>         internalFunc1();
>         // do stuff
>     }
> 
>     private void internalFunc1()
>     {
>         if ( maybe )
>             internalFunc2();
>         else return;
>     }
> 
>     private void internalFunc2()
>     {
>         if ( maybe )
>             internalFunc1();
>         else return;
>     }
> }
> 
> void main()
> {
>     int x = 42;
>     x = F(x);
> }
> 
> Under the hood, it may also behave differently than nested functions, which could be advantageous.  I'm not sure that it is advantageous, but options are always nice.
> 
> That and you can make nice syntax sugars for alternative memory management methods like freelists, without messing with overriding 'new()'. 

I do like using the scope keyword for this btw.  It seems quite consistant with D's meaning of 'scope'.

I vote for banana!

or scope.. seems good to reuse it; without parentheses after scope keyword implying `end of scope destruction`.


On Tue, 25 Jul 2006 13:17:13 -0400, kris <foo@bar.com> wrote:

> Don has a good point: changing to "var" would cause conflict with existing variable-names.
>
> Chad et. al. also have a good point about the conflict regarding static opCall() (via the lack of a "new" keyword). I suspect many people find the use of "new" to be indicative of allocation, and breaking this consistency may have a detrimental effect? Further, it was noted that a missing "new" can only be used at the instantiation site -- not at the class decl -- thus, D would be losing an existing feature.
>
> I suspect you could count the current number of raii-class uses on a few hands, whereas the use of "auto" for implied-type is pretty darned popular -- and rightly so, since it's really very, very useful. Changing the raii style to use a different keyword, whilst retaining implied-type "auto" would be an almost imperceptible change?
>
> Thus, it would appear to make sense to retain "auto" for implied-type, and introduce something *else* for automatic cleanup at end-of-scope (and also as a class attribute). how about reusing the "scope" keyword?
>
> void main()
> {
>    auto i = 10;
>    auto foo = new Foo;
>    auto scope bar = new Bar;
>    auto scope wumpus = new Wumpus;
> }
>
> class Foo {}
>
> class Bar {}
>
> scope class Wumpus {}
>
>
>
>
>
>

On Tue, 25 Jul 2006 23:28:24 -0400, Chad J <gamerChad@_spamIsBad_gmail.com> wrote:
> Regan Heath wrote:
>>   I say lets keep 'auto' for auto type inference (for the reasons you and  Don mention)
>>  I like the use of scope at class decl. But, I prefer the no keyword  approach at instantiation. So, allow me to suggest this as a 3rd option.
>>  - 'scope' at class decl.
>> - no keyword at instatiation.
>>  Reasoning:
>>  'new' implies heap allocation to me. It would be beneficial to allow the  compiler to allocate an RAII type in any way it wants, perhaps stack  allocating it. Removing 'new' removes the implied heap allocation allowing  the compiler to allocate however it likes.
>>
>
> I disagree.
>
> If you want the compiler to be able to optimize by using stack allocation instead of heap allocation, then let it do that with the new keyword.

You miss-understand. I don't want stack allocation at all. I'm saying 2 things:

1. 'new' implies heap allocation
2. lack of 'new' implies _nothing_ about allocation.

The result of which is that the compiler is not _required_ to heap allocate but can allocate in some other fashion.

> I'm assuming the program's behaviour would be the same in either case, so it wouldn't matter to me.
>
> If you want stack allocation then how about
> scope A a = A();
>
> It keeps the concepts of scope and allocation seperate.

It's no different to this:

A a = A();

which says _nothing_ about allocation. It implies only that 'a' will be collected at the end of scope.
The compiler is FREE to allocate however it wants. That _may_ be stack allocation, it _may_ not.

In comparison this:

A a = new A();

currently 'implies' heap allocation.

That's all I was saying. I'm not suggesting stack allocation, I'm suggesting that removing 'new' allows the compiler to allocate however it wants.

You're suggesting 'new' could allocate on the stack, I think that would be unexpected to say the least.

> Scope is not allocation.

Correct. I never said it was. The ability to stack allocate is a by product of removing 'new' nothing else.

>> I don't see the utility in static opCall, I say abolish/remove it.  Non-static opCall on the other hand can be quite useful.
>>  Regan
>
> Please don't abolish/remove it.  At least not until you have convinced me that it is totally useless.

Convince you.. I don't have to convince you, only Walter.
Likewise you have to convince Walter.
;0)

> I really don't like the idea of dropping a language feature just for the sake of having a particular syntax that, IMO, is not intuitive.

It's the same syntax you see in C++ for a class that has it's destructor called at the end of the scope. That, to me, makes it intuitive. For what reason do you find it un-intuitive?

>  From my previous post about this:
>> I like being able to use types as functions.
>> Here's one example where I do something similar to what you'd use nested functions for, but better - my forward referencing woes go away.
>>  class F
>> {
>>     int result;
>>     int tempVar1;
>>      static int opCall( int x )
>>     {
>>         F f = new F(x);
>>         int result = f.result;
>>         delete f;
>>         return result;
>>     }
>>      this( int x )
>>     {
>>         internalFunc1();
>>         // do stuff
>>     }
>>      private void internalFunc1()
>>     {
>>         if ( maybe )
>>             internalFunc2();
>>         else return;
>>     }
>>      private void internalFunc2()
>>     {
>>         if ( maybe )
>>             internalFunc1();
>>         else return;
>>     }
>> }
>>  void main()
>> {
>>     int x = 42;
>>     x = F(x);
>> }
>>  Under the hood, it may also behave differently than nested functions, which could be advantageous.  I'm not sure that it is advantageous, but options are always nice.
>>  That and you can make nice syntax sugars for alternative memory management methods like freelists, without messing with overriding 'new()'.

What's the point of using static opCall here, as opposed to a normal static method or even a free function?
What problem does it solve?
What new technique or method does it allow?

> I do like using the scope keyword for this btw.  It seems quite consistant with D's meaning of 'scope'.

It's not bad but it's my 2nd choice currently.

Regan

On Wed, 26 Jul 2006 00:13:53 -0400, Regan Heath <regan@netwin.co.nz> wrote:
> 1. 'new' implies heap allocation

Except when it doesn't.  I'm talking about overloaded 'new'

If Object`s were given 2 default new() implmentations, one that does the current allocation, and another that allows you to specify a buffer (also so that every Joe who wants this doesn't have to derive from the class to provide it). When RAII is involved, it can choose which version of new() to use (implementaion defined), using stack or not.

On Wed, 26 Jul 2006 00:23:41 -0400, Chris Miller <chris@dprogramming.com> wrote:
> On Wed, 26 Jul 2006 00:13:53 -0400, Regan Heath <regan@netwin.co.nz> wrote:
>> 1. 'new' implies heap allocation
>
> Except when it doesn't.  I'm talking about overloaded 'new'
>
> If Object`s were given 2 default new() implmentations, one that does the current allocation, and another that allows you to specify a buffer (also so that every Joe who wants this doesn't have to derive from the class to provide it). When RAII is involved, it can choose which version of new() to use (implementaion defined), using stack or not.

You're describing 'placement' new, yes?
http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=160&rl=1

I dont think D has placement new, at least not a syntax for it like C++. I could be wrong.

You're right in that if D were to get placement new using the C++ syntax then the suggested RAII syntax (removing 'new') would make it impossible to declare an RAII class using placement new. But, it appears that placement new in D is done with a custom allocator and not a special syntax?

http://www.digitalmars.com/d/memory.html#newdelete

You coud write a custom allocator which would calculate offsets into pre-allocated memory returning that address for each allocation. Essentially placement new without the special syntax.

Has this topic come up before? What was Walters comment on it? I don't recall a discussion on it, I did a quick search and didn't turn up anything specific.

I wonder, does placement new in D have the same restrictions as in C++? i.e. cannot use stack memory, requires explicit 'delete'.

I wonder what constraints the RAII implementation in D puts on how objects are allocated. It's possible they can't be allocated on the stack .. I seem to recall Walter saying he'd like to go there, eventually, but I might be imagining things.

Regan