This is what I'm talking about:

Foo f = Foo(); // RAII
Foo g = new Foo(); // Normal

Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)

How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:

var f = new Foo(); // Normal
auto var g = new Foo(); // RAII

And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.

This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":

Foo f = stack Foo();
Foo g = local Foo();
Foo h = raii Foo();

Something.  Anything would be better than the "new or nothing" syntax.

On Tue, 5 Sep 2006 00:55:56 -0400, Jarrett Billingsley wrote:

> This is what I'm talking about:
> 
> Foo f = Foo(); // RAII
> Foo g = new Foo(); // Normal
> 
> Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
> 
> How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
> 
> var f = new Foo(); // Normal
> auto var g = new Foo(); // RAII
> 
> And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
> 
> This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
> 
> Foo f = stack Foo();
> Foo g = local Foo();
> Foo h = raii Foo();
> 
> Something.  Anything would be better than the "new or nothing" syntax.

I strongly agree with Jarrett.

     Foo f = <NEW> Foo();

  where <NEW> can be either 'new' or 'local', or even 'new local' but never
omitted, when invoking the class constructor. The static opCall is probably
not valuable and if removed I wouldn't mind, but this still would not
justify omitting 'new' either.

BTW, I'm not wedded to 'local' but something, ... anything, that explicitly informs the reader that the object will be destroyed when it goes out of scope is needed. Leaving it out is not a good user interface.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
5/09/2006 2:57:59 PM

Jarrett Billingsley wrote:
> This is what I'm talking about:
> 
> Foo f = Foo(); // RAII
> Foo g = new Foo(); // Normal
> 
> Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
> 
> How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
> 
> var f = new Foo(); // Normal
> auto var g = new Foo(); // RAII
> 
> And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
> 
> This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
> 
> Foo f = stack Foo();
> Foo g = local Foo();
> Foo h = raii Foo();
> 
> Something.  Anything would be better than the "new or nothing" syntax. 
> 
> 

I agree.

It also makes sense to me to use various keywords to determine what kind of allocation is done:

Foo a = new   Foo(); // compiler optimized allocation
Foo b = heap  Foo(); // allocate on heap
Foo c = stack Foo(); // allocate on stack
Foo d = scope Foo(); // raii

Also, it may be wise to make the keyword prefix the lvalue rather than be the allocator, for a reason I saw pointed out by Bruno Medeiros in a previous discussion:

You can't make auto objects out of objects allocated with a function
(like a factory method) instead of inline allocation. For example, the
following cannot be made with a no-allocator-keyword syntax:
  auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
  auto char[] a = read(filename); // can't make an auto here

... so we'd have
scope Foo f = new Foo();
and I don't know why anyone would want to, but someday you could
scope Foo f = heap Foo();

Chad J wrote:
> Jarrett Billingsley wrote:
>> This is what I'm talking about:
>>
>> Foo f = Foo(); // RAII
>> Foo g = new Foo(); // Normal
>>
>> Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
>>
>> How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
>>
>> var f = new Foo(); // Normal
>> auto var g = new Foo(); // RAII
>>
>> And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
>>
>> This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
>>
>> Foo f = stack Foo();
>> Foo g = local Foo();
>> Foo h = raii Foo();
>>
>> Something.  Anything would be better than the "new or nothing" syntax.
>>
> 
> I agree.
> 
> It also makes sense to me to use various keywords to determine what kind of allocation is done:
> 
> Foo a = new   Foo(); // compiler optimized allocation
> Foo b = heap  Foo(); // allocate on heap
> Foo c = stack Foo(); // allocate on stack
> Foo d = scope Foo(); // raii
> 
> Also, it may be wise to make the keyword prefix the lvalue rather than be the allocator, for a reason I saw pointed out by Bruno Medeiros in a previous discussion:
> 
> You can't make auto objects out of objects allocated with a function
> (like a factory method) instead of inline allocation. For example, the
> following cannot be made with a no-allocator-keyword syntax:
>   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
>   auto char[] a = read(filename); // can't make an auto here
> 
> ... so we'd have
> scope Foo f = new Foo();
> and I don't know why anyone would want to, but someday you could
> scope Foo f = heap Foo();

Specifying storage mechanism seems like unnecessary compiler hamstringing.  Specify behavior and give the compiler authors the freedom to detect and optimize the storage.  See previous discussions on escape analysis.

Ages ago it was realized in the C language and descendants that the 'register' keyword was pointless and, as far as I know, no compiler today obeys it.  Let's not repeat that misfeature.

Later,
Brad

Derek Parnell wrote:
> 
> I strongly agree with Jarrett. 
> 
>      Foo f = <NEW> Foo();
> 
>   where <NEW> can be either 'new' or 'local', or even 'new local' but never
> omitted, when invoking the class constructor. The static opCall is probably
> not valuable and if removed I wouldn't mind, but this still would not
> justify omitting 'new' either.
> 
> BTW, I'm not wedded to 'local' but something, ... anything, that explicitly
> informs the reader that the object will be destroyed when it goes out of
> scope is needed. Leaving it out is not a good user interface.

If there's to be a symbol to signify "stack allocation" then it should be in place of <NEW> as Derek suggests and not preceding the entire declaration as 'auto' does now.  I'll admit I prefer this idea to having nothing there, but I could live with either.


Sean

Brad Roberts wrote:
> Chad J wrote:
> 
>> Jarrett Billingsley wrote:
>>
>>> This is what I'm talking about:
>>>
>>> Foo f = Foo(); // RAII
>>> Foo g = new Foo(); // Normal
>>>
>>> Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
>>>
>>> How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
>>>
>>> var f = new Foo(); // Normal
>>> auto var g = new Foo(); // RAII
>>>
>>> And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
>>>
>>> This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
>>>
>>> Foo f = stack Foo();
>>> Foo g = local Foo();
>>> Foo h = raii Foo();
>>>
>>> Something.  Anything would be better than the "new or nothing" syntax.
>>>
>>
>> I agree.
>>
>> It also makes sense to me to use various keywords to determine what kind of allocation is done:
>>
>> Foo a = new   Foo(); // compiler optimized allocation
>> Foo b = heap  Foo(); // allocate on heap
>> Foo c = stack Foo(); // allocate on stack
>> Foo d = scope Foo(); // raii
>>
>> Also, it may be wise to make the keyword prefix the lvalue rather than be the allocator, for a reason I saw pointed out by Bruno Medeiros in a previous discussion:
>>
>> You can't make auto objects out of objects allocated with a function
>> (like a factory method) instead of inline allocation. For example, the
>> following cannot be made with a no-allocator-keyword syntax:
>>   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
>>   auto char[] a = read(filename); // can't make an auto here
>>
>> ... so we'd have
>> scope Foo f = new Foo();
>> and I don't know why anyone would want to, but someday you could
>> scope Foo f = heap Foo();
> 

The following works right now, and does so just fine:
    Foo foo = SomeFactory.newFoo(...); scope(exit) delete foo;
    char[] a = read(filename); scope(exit) delete a;

-- Chris Nicholson-Sauls

Jarrett Billingsley wrote:
> This is what I'm talking about:
> 
> Foo f = Foo(); // RAII
> Foo g = new Foo(); // Normal
> 
> Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
> 
> How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
> 
> var f = new Foo(); // Normal
> auto var g = new Foo(); // RAII
> 
> And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
> 
> This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
> 
> Foo f = stack Foo();
> Foo g = local Foo();
> Foo h = raii Foo();
> 
> Something.  Anything would be better than the "new or nothing" syntax. 
> 
> 

I despise writing "me too" posts, but in this case I just cannot avoid it.  So... me too!

I also find it intriguing that Phobos' RegExp module includes the following:
#    public static RegExp opCall(rchar[] pattern, rchar[] attributes = null)
#    {
#        return new RegExp(pattern, attributes);
#    }

Yes in this case it is nothing but a wrapper around the constructor, and essentially useless so far as I can tell.  However, the fact that Walter felt compelled to provide such a creature is telling.

Personally I favor either 'local' or 'scope'/'scoped' as a new keyword for this purpose, and do believe as others that it belongs in 'new's current position.  The option of 'scope'/'scoped' has the added benefit of consistancy with current keywords and usage.

-- Chris Nicholson-Sauls

I'm a fan of the local keyword, or perhaps combining with the existing scope keywords as follows:

local:

local File file = new File(); // local RAII
local auto file = new File(); // local RAII + auto typing

or

scope(local):

scope(local) File file = new File();
scope(local) auto file = new File();

scope(local) is a little long for a single line, but it begins to look better if you have a group of RAII variables:

scope(local)
{
	File file;
	RecordSet rs;
	// etc
}


I believe that if we keep the auto/auto syntax, it will be a feature that everyone will love at first, but years from now it'll be the feature that we'll be cursing when we all have to maintain code. Scanning code quickly its hard to determine with the current auto/auto syntax if its RAII or auto typing.

Rob


Jarrett Billingsley wrote:
> This is what I'm talking about:
> 
> Foo f = Foo(); // RAII
> Foo g = new Foo(); // Normal
> 
> Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
> 
> How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
> 
> var f = new Foo(); // Normal
> auto var g = new Foo(); // RAII
> 
> And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
> 
> This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
> 
> Foo f = stack Foo();
> Foo g = local Foo();
> Foo h = raii Foo();
> 
> Something.  Anything would be better than the "new or nothing" syntax. 
> 
> 

On Tue, 05 Sep 2006 19:30:30 +0300, Robert Atkinson <Robert.Atkinson@NO.gmail.com.SPAM> wrote:
[snip]
> I believe that if we keep the auto/auto syntax, it will be a feature that everyone will love at first, but years from now it'll be the feature that we'll be cursing when we all have to maintain code. Scanning code quickly its hard to determine with the current auto/auto syntax if its RAII or auto typing.
>
> Rob

Well, I got confused right away (when I discovered D). ;) (And hence never liked the auto/auto syntax.)

I think it really should be changed.


> Jarrett Billingsley wrote:
>> This is what I'm talking about:
>>  Foo f = Foo(); // RAII
>> Foo g = new Foo(); // Normal
>>  Can we all discuss this?  I'm sorry, but that syntax is just too easy to mess up / miss.  I'm surprised that you, someone who is very much against "secret things happening" would be a proponent of this syntax.  It's just too nonobvious.  (And as a minor point, this also makes it impossible to make a static opCall with a class.)
>>  How about instead, we keep auto to mean a RAII reference, and we take the C# route for type inference and come up with a "var" keyword which would be a "type placeholder".  That is:
>>  var f = new Foo(); // Normal
>> auto var g = new Foo(); // RAII
>>  And as you can see, this gets rid of thee "auto auto" problem.  Not to mention it gets rid of the very common misunderstanding that currently, "auto" is somehow used for type inference, when in fact it's simply the use of a storage class without a type that invokes type inference.
>>  This, or maybe we could use a "stack" or "local" or "raii" keyword in place of the "new":
>>  Foo f = stack Foo();
>> Foo g = local Foo();
>> Foo h = raii Foo();
>>  Something.  Anything would be better than the "new or nothing" syntax.
>

+1 :)

I'm terrified of 'auto auto' making it into 1.0; it just -screams- "ugly and confusing" to me.