"Tomas Lindquist Olsen" <tomas@famolsen.dk> wrote in message news:eja9o7$2sd4$1@digitaldaemon.com...
> JC wrote:
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ej9acb$1sac$2@digitaldaemon.com...
>>> Tomas Lindquist Olsen wrote:
>>>> *shivers* by the thought of 'var'
>>> I knew that somehow I couldn't be the only one <g>.
>>
>> I don't see much wrong with 'var'.
>
> My issue with 'var' is that it looks ugly and doesn't really tell you that RAII is in action.

Ugliness is in the eye of the beholder. And 'var' was never proposed for RAII.

"Kristian Kilpi" <kjkilpi@gmail.com> wrote in message news:op.tiyvn2xqusumhd@mist...
>> It has the nice connotation that it represents a variable, at least.
>
> The other storage classes work for variables too!
>
>> As for RAII, just using a keyword alone doesn't seem to cut it. If
>> references are to be automatically deleted at the end of a scope, that
>> infers that a scope is actually introduced, which to me is signified by
>> a matching pair of curly brackets. I'd like to be able to specify the
>> extent of the scope, perhaps like this:
>>  void drawBox(Rectangle rect, Colour colour) {
>>   scope (DrawingContext dc = createDrawingContext()) {
>>     scope (Pen pen = new Pen(colour)) {
>>       dc.drawRectangle(pen, rect);
>>     } // pen is freed here
>>   } // dc is freed here
>> }
>>  Used this way, 'scope' as the RAII keyword makes sense.
>
> *Please* no!

> Also I don't like this syntax. All variables should always be declared at the begining of blocks.

According to whom? That's a style thing, not a rule.

JC wrote:
> "Tomas Lindquist Olsen" <tomas@famolsen.dk> wrote in message news:eja9o7$2sd4$1@digitaldaemon.com...
>> JC wrote:
>>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:ej9acb$1sac$2@digitaldaemon.com...
>>>> Tomas Lindquist Olsen wrote:
>>>>> *shivers* by the thought of 'var'
>>>> I knew that somehow I couldn't be the only one <g>.
>>> I don't see much wrong with 'var'.
>> My issue with 'var' is that it looks ugly and doesn't really tell you that RAII is in action.
> 
> Ugliness is in the eye of the beholder. And 'var' was never proposed for RAII. 
> 
> 
I realise (and was pointed out already that I misunderstood). Ugliness is definitely in the eye of the beholder. For me 'var' makes D look like a dynamically typed language, though I'm obviously biased!

On Mon, 13 Nov 2006 20:40:23 +0200, JC <johnch_atms@hotmail.com> wrote:

> "Kristian Kilpi" <kjkilpi@gmail.com> wrote in message
> news:op.tiyvn2xqusumhd@mist...
>>> It has the nice connotation that it represents a variable, at least.
>>
>> The other storage classes work for variables too!
>>
>>> As for RAII, just using a keyword alone doesn't seem to cut it. If
>>> references are to be automatically deleted at the end of a scope, that
>>> infers that a scope is actually introduced, which to me is signified by
>>> a matching pair of curly brackets. I'd like to be able to specify the
>>> extent of the scope, perhaps like this:
>>>  void drawBox(Rectangle rect, Colour colour) {
>>>   scope (DrawingContext dc = createDrawingContext()) {
>>>     scope (Pen pen = new Pen(colour)) {
>>>       dc.drawRectangle(pen, rect);
>>>     } // pen is freed here
>>>   } // dc is freed here
>>> }
>>>  Used this way, 'scope' as the RAII keyword makes sense.
>>
>> *Please* no!
>
>> Also I don't like this syntax. All variables should always be declared at
>> the begining of blocks.
>
> According to whom? That's a style thing, not a rule.
>

Yes, that was just my humble opinion. :)

I just think that it would be consistent if all the variables will be declared in the same place. In addition, that would add an extra level of indentation. I would like to write:

  void func() {
    int a;
    scoped file = new File;
    ...
    }

instead of:

  void func() {
    int a;
    scope(file = new File) {
      ...
      }
    }

And it gets complicated when more than one scoped variable will be used, IMHO.

Kristian Kilpi wrote:
> On Mon, 13 Nov 2006 20:40:23 +0200, JC <johnch_atms@hotmail.com> wrote:

>>> Also I don't like this syntax. All variables should always be declared  at
>>> the begining of blocks.
>>
>>
>> According to whom? That's a style thing, not a rule.
>>
> 
> Yes, that was just my humble opinion. :)
> 
> I just think that it would be consistent if all the variables will be  declared in the same place. 

You're free to have your opinion, but the C++ books I've read disagree with you.    The ones I've read advocate declaring variables as close to the point of usage as possible.  (Can't remember which books exactly, but probably Stroustrup and/or Meyers' books.)

--bb

Nils Hensel wrote:
> Using a storage class for type inference is an easy and coherent method
> and since C++ will use "auto" for type inference it isn't such a bad
> choice after all. Perhaps I got used to it after all.

I too think the (future) C++ use of 'auto' for type inference cinches it.

> I still think though that it should only mean that.

At this point, I agree.

Another argument for using 'auto' for ATI can be making it consistent with how it currently works for classes in DMD:

class A
{
	static
	{
		auto x = 2;
		auto y = 42;
	}
	auto z = 27;
}

This works. x and y are static!

Walter Bright wrote:
> Carlos Santander wrote:
>> I don't think they're valid concerns (meaning they're subjective, not everyone will have those ideas), but I think we (the D community) just want a way to clearly differentiate both meanings of auto. So, choose any two words: auto/scope, var/auto, def/scoped, foo/bar, and let's move on.
> 
> I think the auto/scope is probably the best idea.
> 
>> Also keep in mind that your option #5 (auto c = Class()) doesn't seem to be a popular proposal (based on what has been said in the ng).
> 
> I'm a bit surprised at that, but the negative reaction to it is pretty clear.

Seems I was one of the few who actually sort of liked the proposals.  So where do we stand now?  I couldn't see much of a consensus.  I gather that type inference may remain as is, since it works, is clear (IMO), and doesn't introduce any new keywords.  But I'm a bit fuzzy on whether anything was decided for RAII.  Most folks seem to dislike the original proposal for two reasons:

* It conflicts with static opCall.
* It isn't easy to distinguish/grep such a declaration vs. a 'new' declaration.

And most seem to favor the addition of a new keyword, probably 'scope' somewhere in the declaration.  popular form seems to be:

    scope MyClass c = new MyClass(); // scoped decl
    auto scope c    = new MyClass(); // inferred scoped decl

Is this correct so far?  And if so, I'd like to re-iterate my concerns about such a syntax:

With the above, the 'scope' identifier is associated with the reference, not the data.  Thus, it would be equivalent to:

    MyClass c = new MyClass();
    scope(exit) delete c;

This raises a host of issues if such references are reassignable, and in the worst case would mean that scoped data could not be allocated on the stack unless the compiler had some form of escape detection.  For example:

    scope MyClass c = new MyClass();
    c = new MyClass();
    MyClass d = c;
    return d;

Here, we have a new instance of MyClass that should be destroyed on scope exit (by my understanding).  However, c is reassigned to a new instance of MyClass before this occurs.  The current result is that the new instance is destroyed instead of the old one and the old one will remain in memory until the next GC collection.  Also, 'd' will return a reference to data that no longer exists since it will be destroyed when 'c' goes out of scope.  Even worse:

    scope MyClass c = new MyClass();
    scope MyClass d = c;

Here, we have two scoped references both referring to the same piece of data, which results in a double-deletion.  Therefore, to be implemented correctly and safely, such references must uniquely refer to the underlying data, much like C++'s auto_ptr.  Finally:

    scope int* i = new int;

What happens here?  Will the compiler disallow the use of 'scope' on non-class types, will 'i' be deleted on scope exit, or will 'scope' simply be ingored?

If we are truly to use the 'scope' keyword for RAII objects, I humbly request that the data be flagged instead of the reference.  Here are two suggestions for syntax:

    MyClass c = scope MyClass();
    MyClass c = new(scope) MyClass();

Both would allow data to be allocated on the stack without escape detection (or an assumption that the user isn't being evil), and the latter is even almost identical to how alloca is used now.  I dislike that both would make class allocation semantically different from concrete type allocation, but anything is better than associating 'scope' with the reference itself, for the reasons illustrated above.


Sean

On Mon, 13 Nov 2006 21:17:32 +0200, Bill Baxter <wbaxter@gmail.com> wrote:

> Kristian Kilpi wrote:
>> On Mon, 13 Nov 2006 20:40:23 +0200, JC <johnch_atms@hotmail.com> wrote:
>
>>>> Also I don't like this syntax. All variables should always be declared  at
>>>> the begining of blocks.
>>>
>>>
>>> According to whom? That's a style thing, not a rule.
>>>
>>  Yes, that was just my humble opinion. :)
>>  I just think that it would be consistent if all the variables will be  declared in the same place.
>
> You're free to have your opinion, but the C++ books I've read disagree with you.    The ones I've read advocate declaring variables as close to the point of usage as possible.  (Can't remember which books exactly, but probably Stroustrup and/or Meyers' books.)
>
> --bb

Hehheh. Ok, I think I understant the point behind that. Well, I guess both the styles have their own advantages and disadvantages. The style where one declares (almost) all the variables at the begining of the (main) block works for me. Sorry for assuming that this style is the Correct Way(TM)... ;)

Tomas Lindquist Olsen wrote:
> Another argument for using 'auto' for ATI can be making it consistent with how it currently works for classes in DMD:
> 
> class A
> {
>     static
>     {
>         auto x = 2;
>         auto y = 42;
>     }
>     auto z = 27;
> }
> 
> This works. x and y are static!

I think this works everywhere, as you're free to chain storage classes to your heart's delight:

    // what is this??
    auto const static const static auto x = 5;


Sean