Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
> On Tue, 26 Apr 2011 19:45:21 -0400, Daniel Gibson <metalcaedes@gmail.com> wrote:
> 
>> I just noticed something regarding clear():
>>   struct Bar { ... }
>>   Bar *b = new Bar();
>> This compiles without any warning, but doesn't call the destructor:
>>   clear(b);
>> This compiles without any warning and actually does what you'd expect,
>> i.e. calls destructor:
>>   clear(*b);
>>
>> Is this behavior expected/wanted? If not: Is it a known bug? I couldn't find it in the bugtracker, but maybe I searched for the wrong keywords.
> 
> Let's start with class references.  Because class references cannot be separated from its reference, you have to finalize the class when finalizing the reference, because there's no way to say "clear what this reference refers to" vs. "clear this reference".  So you have to give a way to finalize a class instance.
> 
> With pointers, however, you can specify as you say, whether you want to clear the pointer or the struct itself.
> 
> Now, is it much useful to clear a pointer without clearing what it points to?  I'd say no, clearing a pointer is as easy as doing ptr = null.  So I'm thinking, it should be filed as a bug.
> 
> The obvious thing to decide is, what should be done on references to references?  If you clear a double pointer, should it go through both pointers?  Or a pointer to a class reference?
> 
> I'd say no, but you have to take extra steps to ensure it is this way.
> 
> -Steve

IMHO clear isn't needed for anything but structs and Objects.
For any simple type or pointer you can just write x = x.init; instead of
clear(x) or, as you already mentioned, x=null; for pointers.

AFAIK the main purpose of clear() is to explicitly call the destructor -
and that only makes sense for structs and classes.
Allowing it for other types (especially pointers) just sneaks in
non-obvious bugs, especially when it's considered a replacement for
delete (which calls the destructor for both Object a *struct).

BTW: clear() has often been mentioned in this NG but isn't documented in
the Phobos documentation (which is no surprise because clear() doesn't
have doc-comments).

So I guess I'll report this as a bug.

Cheers,
- Daniel

On Tue, 26 Apr 2011 20:15:45 -0400, Daniel Gibson <metalcaedes@gmail.com> wrote:

> Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
>> On Tue, 26 Apr 2011 19:45:21 -0400, Daniel Gibson
>> <metalcaedes@gmail.com> wrote:
>>
>>> I just noticed something regarding clear():
>>>   struct Bar { ... }
>>>   Bar *b = new Bar();
>>> This compiles without any warning, but doesn't call the destructor:
>>>   clear(b);
>>> This compiles without any warning and actually does what you'd expect,
>>> i.e. calls destructor:
>>>   clear(*b);
>>>
>>> Is this behavior expected/wanted? If not: Is it a known bug? I couldn't
>>> find it in the bugtracker, but maybe I searched for the wrong keywords.
>>
>> Let's start with class references.  Because class references cannot be
>> separated from its reference, you have to finalize the class when
>> finalizing the reference, because there's no way to say "clear what this
>> reference refers to" vs. "clear this reference".  So you have to give a
>> way to finalize a class instance.
>>
>> With pointers, however, you can specify as you say, whether you want to
>> clear the pointer or the struct itself.
>>
>> Now, is it much useful to clear a pointer without clearing what it
>> points to?  I'd say no, clearing a pointer is as easy as doing ptr =
>> null.  So I'm thinking, it should be filed as a bug.
>>
>> The obvious thing to decide is, what should be done on references to
>> references?  If you clear a double pointer, should it go through both
>> pointers?  Or a pointer to a class reference?
>>
>> I'd say no, but you have to take extra steps to ensure it is this way.
>>
>> -Steve
>
> IMHO clear isn't needed for anything but structs and Objects.
> For any simple type or pointer you can just write x = x.init; instead of
> clear(x) or, as you already mentioned, x=null; for pointers.

It is useful for it to work for generic code.

> AFAIK the main purpose of clear() is to explicitly call the destructor -
> and that only makes sense for structs and classes.
> Allowing it for other types (especially pointers) just sneaks in
> non-obvious bugs, especially when it's considered a replacement for
> delete (which calls the destructor for both Object a *struct).

I'm not sure it introduces subtle bugs for things besides pointers.  Clearing an int should be harmless.

> BTW: clear() has often been mentioned in this NG but isn't documented in
> the Phobos documentation (which is no surprise because clear() doesn't
> have doc-comments).
>
> So I guess I'll report this as a bug.

If you mean that clear has no docs, I already reported that.

http://d.puremagic.com/issues/show_bug.cgi?id=5855

Feel free to report the enhancement request for clear to dereference pointers.

-Steve

Am 27.04.2011 02:26, schrieb Steven Schveighoffer:
> On Tue, 26 Apr 2011 20:15:45 -0400, Daniel Gibson <metalcaedes@gmail.com> wrote:
> 
>> Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
>>> On Tue, 26 Apr 2011 19:45:21 -0400, Daniel Gibson <metalcaedes@gmail.com> wrote:
>>>
>>>> I just noticed something regarding clear():
>>>>   struct Bar { ... }
>>>>   Bar *b = new Bar();
>>>> This compiles without any warning, but doesn't call the destructor:
>>>>   clear(b);
>>>> This compiles without any warning and actually does what you'd expect,
>>>> i.e. calls destructor:
>>>>   clear(*b);
>>>>
>>>> Is this behavior expected/wanted? If not: Is it a known bug? I couldn't find it in the bugtracker, but maybe I searched for the wrong keywords.
>>>
>>> Let's start with class references.  Because class references cannot be separated from its reference, you have to finalize the class when finalizing the reference, because there's no way to say "clear what this reference refers to" vs. "clear this reference".  So you have to give a way to finalize a class instance.
>>>
>>> With pointers, however, you can specify as you say, whether you want to clear the pointer or the struct itself.
>>>
>>> Now, is it much useful to clear a pointer without clearing what it points to?  I'd say no, clearing a pointer is as easy as doing ptr = null.  So I'm thinking, it should be filed as a bug.
>>>
>>> The obvious thing to decide is, what should be done on references to references?  If you clear a double pointer, should it go through both pointers?  Or a pointer to a class reference?
>>>
>>> I'd say no, but you have to take extra steps to ensure it is this way.
>>>
>>> -Steve
>>
>> IMHO clear isn't needed for anything but structs and Objects.
>> For any simple type or pointer you can just write x = x.init; instead of
>> clear(x) or, as you already mentioned, x=null; for pointers.
> 
> It is useful for it to work for generic code.
> 
>> AFAIK the main purpose of clear() is to explicitly call the destructor -
>> and that only makes sense for structs and classes.
>> Allowing it for other types (especially pointers) just sneaks in
>> non-obvious bugs, especially when it's considered a replacement for
>> delete (which calls the destructor for both Object a *struct).
> 
> I'm not sure it introduces subtle bugs for things besides pointers. Clearing an int should be harmless.
> 
>> BTW: clear() has often been mentioned in this NG but isn't documented in
>> the Phobos documentation (which is no surprise because clear() doesn't
>> have doc-comments).
>>
>> So I guess I'll report this as a bug.
> 
> If you mean that clear has no docs, I already reported that.
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=5855
> 
> Feel free to report the enhancement request for clear to dereference pointers.
> 
> -Steve

Done: http://d.puremagic.com/issues/show_bug.cgi?id=5895

== Quote from Daniel Gibson (metalcaedes@gmail.com)'s article
> Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
> IMHO clear isn't needed for anything but structs and Objects.
> For any simple type or pointer you can just write x = x.init; instead of
> clear(x) or, as you already mentioned, x=null; for pointers.
> AFAIK the main purpose of clear() is to explicitly call the destructor -
> and that only makes sense for structs and classes.
> Allowing it for other types (especially pointers) just sneaks in
> non-obvious bugs, especially when it's considered a replacement for
> delete (which calls the destructor for both Object a *struct).
> BTW: clear() has often been mentioned in this NG but isn't documented in
> the Phobos documentation (which is no surprise because clear() doesn't
> have doc-comments).
> So I guess I'll report this as a bug.
> Cheers,
> - Daniel

Regarding clear(), has the implementation already been corrected so that it does *not* call the constructor after object destruction?

On Wed, 27 Apr 2011 03:09:41 -0400, Francisco Almeida <francisco.m.almeida@gmail.com> wrote:

> == Quote from Daniel Gibson (metalcaedes@gmail.com)'s article
>> Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
>> IMHO clear isn't needed for anything but structs and Objects.
>> For any simple type or pointer you can just write x = x.init; instead of
>> clear(x) or, as you already mentioned, x=null; for pointers.
>> AFAIK the main purpose of clear() is to explicitly call the destructor -
>> and that only makes sense for structs and classes.
>> Allowing it for other types (especially pointers) just sneaks in
>> non-obvious bugs, especially when it's considered a replacement for
>> delete (which calls the destructor for both Object a *struct).
>> BTW: clear() has often been mentioned in this NG but isn't documented in
>> the Phobos documentation (which is no surprise because clear() doesn't
>> have doc-comments).
>> So I guess I'll report this as a bug.
>> Cheers,
>> - Daniel
>
> Regarding clear(), has the implementation already been corrected so that it does
> *not* call the constructor after object destruction?

It's fixed in the latest git repository (BTW, how does one refer to the git "trunk"?)

It's not in 2.052

-Steve

On 2011-04-27 15:00, Steven Schveighoffer wrote:
> On Wed, 27 Apr 2011 03:09:41 -0400, Francisco Almeida
> <francisco.m.almeida@gmail.com> wrote:
>
>> == Quote from Daniel Gibson (metalcaedes@gmail.com)'s article
>>> Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
>>> IMHO clear isn't needed for anything but structs and Objects.
>>> For any simple type or pointer you can just write x = x.init; instead of
>>> clear(x) or, as you already mentioned, x=null; for pointers.
>>> AFAIK the main purpose of clear() is to explicitly call the destructor -
>>> and that only makes sense for structs and classes.
>>> Allowing it for other types (especially pointers) just sneaks in
>>> non-obvious bugs, especially when it's considered a replacement for
>>> delete (which calls the destructor for both Object a *struct).
>>> BTW: clear() has often been mentioned in this NG but isn't documented in
>>> the Phobos documentation (which is no surprise because clear() doesn't
>>> have doc-comments).
>>> So I guess I'll report this as a bug.
>>> Cheers,
>>> - Daniel
>>
>> Regarding clear(), has the implementation already been corrected so
>> that it does
>> *not* call the constructor after object destruction?
>
> It's fixed in the latest git repository (BTW, how does one refer to the
> git "trunk"?)
>
> It's not in 2.052
>
> -Steve

"head" or to be exact "HEAD" if you were wondering what to call it.
-- 
/Jacob Carlborg

On Wed, 27 Apr 2011 10:17:30 -0400, Jacob Carlborg <doob@me.com> wrote:

> "head" or to be exact "HEAD" if you were wondering what to call it.

Yes, thank you (that's twice you answered my naming questions, perhaps I should just email you directly next time ;)

-Steve

2011/4/26 Timon Gehr <timon.gehr@gmx.ch>:
> But you understand why it is deprecated for GC memory?
>
> The main thing to note is that the semantics of C++ 'new' and D 'new' are rather
> different.
> D 'new' performs allocation on the GC heap by default. The only sane overloads of
> 'new' would therefore allocate the object on a custom GC heap, which you never
> want to do. So there is absolutely no way to overload the 'new' operator
> meaningfully inside the D language. The argument for removing 'delete' overloading
> is trivial after taking that into consideration.
>
> You can still create custom allocators by the means of template functions. (I do not think this is optimal though because they duplicate code that needn't be) They feel a little bit less natural though, which is not a problem, since in D, custom allocators and manual memory management in general, _are_ less natural.

One thing that is perhaps obvious, but eludes me; when dropping the delete-operator, are there any obvious reason to not also drop the "new" keyword? ("new" is a fairly good method/variable name, if nothing else)

I could see two possible alternatives:

Global (and defined-by-default) template new!(Type): (as suggested
elsewhere in this thread by so)
  This is very close to the current situation, but makes it possible
to use as a method-name, and clearly states there's nothing "magic"
about it.

Explicit Allocator, such as GC.new!(Type).
  Would have the benefit of clearly showing who did the allocation,
and would map nicely to other allocators. (Malloc.new/free!(T)!(T)).

  It would also allow library-methods that might allocate instances,
take an allocator as an optional template argument. I.E.
    auto obj = dict.createObject("key");
  OR
    auto obj = dict.createObject!(Malloc)("key");
    scope(exit) Malloc.free(obj);

Possibly an obvious bad idea, but I haven't seen it discussed?

Regards
/ Ulrik

On 2011-04-27 16:25, Steven Schveighoffer wrote:
> On Wed, 27 Apr 2011 10:17:30 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> "head" or to be exact "HEAD" if you were wondering what to call it.
>
> Yes, thank you (that's twice you answered my naming questions, perhaps I
> should just email you directly next time ;)
>
> -Steve

Hehe :)

-- 
/Jacob Carlborg

2011/4/27 Jacob Carlborg <doob@me.com>:
>
> "head" or to be exact "HEAD" if you were wondering what to call it.
> --
> /Jacob Carlborg
>

Sorry to be nit-picking, but HEAD is whatever branch or commit is currently checked out into your working-copy. The git-equivalent of SVN-"trunk" is "master". The default-name of the branch that usually contains published stuff. (Although just as in SVN it's a convention, not a rule.)