Tommie Gannert wrote:
>>>> 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.
>>>
>>> But there is utility in static opCall in structs; having them there but not in classes doesn't sound to cool/consistent..
>>
>> The only utility in static opCall is to emulate a constructor. Why not replace them with a constructor (ie. rename "static opCall" to "this"). Then, remove static opCall altogether.
> 
> I haven't been following this, but static opCall sounds an awful lot like a function call to a function with static variables... I must join the "who would want such a thing"-side.

Support for static operator functions can be useful for refactoring code in some cases, or for some odd template uses.  I don't use the feature very often, but it's nice to have available.


Sean

"Chris Miller" <chris@dprogramming.com> wrote in message news:op.tc91g1fjpo9bzi@moe...
> I vote for banana!

banana++

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

I like scope for RAII too.  Wonder who originally suggested that *cough*cough* ;)

I think "local" may be a better name. At least I don't think I have ever used a variable with that name.


kris 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 Wed, 26 Jul 2006 01:23:53 -0400, Regan Heath <regan@netwin.co.nz> wrote:

> 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

I hadn't thought of 'placement' new but this page is what I was referring to. Scroll down to "Allocating Class Instances On The Stack" to see what I meant. Different uses of 'new' (RAII/regular) could call different new()s, which doesn't imply heap.

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

Conceptually 'auto' as a scope variable indicator is redundant.

In 'ideal D world' struct shall have ctor/dtor and entities
required stack allocation shall be declared as structs - not classes.

So if you need pure stack allocated object use struct with dtor. And if you need class instance to be managed by stack variable use simple struct based smart pointer:

struct local(T)
{
    T ptr;
    void opAssign(T t) { ptr = t; }
    ~this() { delete ptr; }
}

void main()
{
    local!(Bar) bar = new Bar; // opAssign invovation
    ... do something ...
} // implicit dtor invocation happens here ->  delete bar.ptr

Andrew Fedoniouk.
http://terrainformatica.com

Chris Miller wrote:
> On Wed, 26 Jul 2006 01:23:53 -0400, Regan Heath <regan@netwin.co.nz> wrote:
>>
>> http://www.digitalmars.com/d/memory.html#newdelete
> 
> I hadn't thought of 'placement' new but this page is what I was referring to. Scroll down to "Allocating Class Instances On The Stack" to see what I meant. Different uses of 'new' (RAII/regular) could call different new()s, which doesn't imply heap.

This is placement new--the parameter to new specifies the location where the object will be constructed.


Sean

On Wed, 26 Jul 2006 02:52:06 -0700, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:

> vote++;
> //me likes
>

I am sympathetic to the "scope" suggestion also.  People have to remember that Walter doesn't like adding any new keywords.  Reuse of "scope" may be the best solution here.  Are there any drawbacks? Does it fit the intended meaning and purpose appropriately?  It seems to.

-JJR

John Reimer wrote:
> On Wed, 26 Jul 2006 02:52:06 -0700, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
> 
>> vote++;
>> //me likes
>>
> 
> I am sympathetic to the "scope" suggestion also.  People have to remember that Walter doesn't like adding any new keywords.  Reuse of "scope" may be the best solution here.  Are there any drawbacks? Does it fit the intended meaning and purpose appropriately?  It seems to.

Given the suggested placement, I assume it would be illegal to reassign a 'scope' reference to another object?  ie.

    class C {}

    scope C var = new C();
    var = new C();

Assuming a reassignment is allowed, I assume the original object would not be destroyed on scope exit?  Basically, I'm wondering whether the 'scope' qualifier is attached to the reference or to the referent.


Sean

kris wrote:
> 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;
> }

I've argued in the past about being able to elide the 'new' keyword entirely. I like the Python semantics, where 'calling' a class is synonymous with calling a factory function that returns instances of the class. The 'new' keyword is just redundant... until you remember that D has static opCall.

So, without imposing an arbitrary restriction of disallowing static opCall for classes (but not for structs!), or saying e.g. that you have to say "new" for any class with static opCall defined for it (which would just be a huge headache)... I think this is the best solution.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Sean Kelly wrote:
> John Reimer wrote:
> 
>> On Wed, 26 Jul 2006 02:52:06 -0700, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
>>
>>> vote++;
>>> //me likes
>>>
>>
>> I am sympathetic to the "scope" suggestion also.  People have to remember that Walter doesn't like adding any new keywords.  Reuse of "scope" may be the best solution here.  Are there any drawbacks? Does it fit the intended meaning and purpose appropriately?  It seems to.
> 
> 
> Given the suggested placement, I assume it would be illegal to reassign a 'scope' reference to another object?  ie.
> 
>     class C {}
> 
>     scope C var = new C();
>     var = new C();
> 
> Assuming a reassignment is allowed, I assume the original object would not be destroyed on scope exit?  Basically, I'm wondering whether the 'scope' qualifier is attached to the reference or to the referent.
> 
> 
> Sean

Maybe we could decide that based on the keyword's placement:

class C {
    int m_i;
    this(int i) { m_i = i; }
    int i() { return m_i; }
}

scope C a = new C(1); // Destroy 'a' at end of scope
C b = a; // b is another reference to 1. It will be invalid at the
         // end of scope, except:
a = new C(2); // No, whoops! Destroy 2 at end of scope.
              // 1 is now referenced by b alone.
return b; // Allowed! The reference 'a' will no longer destroy 1.
return a; // NOT allowed! a is a scoped reference

The alternative:

C a = scope new C(1); // Destroy 1 at end of scope.
C b = a; // b is another reference to 1, which will be destroyed
         // at the end of scope.
a = new C(2); // A new, plain-old GCed instance.
return b; // NOT allowed! 1 is invalid after this scope.
return a; // Okay. a is a reference to a regular object.

Maybe we could allow both?

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki