On Apr 28, 11 04:28, Daniel Gibson wrote:
> It'd create template bloat and uglier syntax (expecially confusing for
> people coming from about any other popular OO language) for a really
> common, standard feature.
> These drawbacks are acceptable for custom allocation and other stuff the
> average user shouldn't care about, but not for an elemental feature like
> "new".
>
> Cheers,
> - Daniel

Er elemental? If 'new' is deprecated then a 'class' and 'array' will be constructed with

    class K { ... }
    auto k = K(...);           // no new
    auto a = int[] (k.length); // no new

same as how a 'struct' is constructed now. The only situation left where 'new!T()' is really necessary is when you need to create a T* on heap (GC.malloc) e.g.

    int* ps = new!int(4);

I fail to see this is elemental in D.

Am 27.04.2011 22:53, schrieb so:
> On Wed, 27 Apr 2011 23:42:59 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote:
> 
>> Am 27.04.2011 22:41, schrieb Daniel Gibson:
>>> Am 27.04.2011 22:37, schrieb so:
>>>>> It'd create template bloat and uglier syntax (expecially confusing for
>>>>> people coming from about any other popular OO language) for a really
>>>>> common, standard feature.
>>>>> These drawbacks are acceptable for custom allocation and other
>>>>> stuff the
>>>>> average user shouldn't care about, but not for an elemental feature
>>>>> like
>>>>> "new".
>>>>>
>>>>> Cheers,
>>>>> - Daniel
>>>>
>>>> For the template bloat, yes that would be a problem.
>>>> But it is not ugly! Take it back! :)
>>>>
>>>> auto a = new A;
>>>> auto a = new!A();
>>>>
>>>> auto b = new B(5);
>>>> auto b = new!B(5);
>>>>
>>>> For the confusion part, the real confusion (rather shock) awaits when
>>>> they get to the part where they see "new" but no "delete".
>>>> We could argue against this all the way, but to every single of us
>>>> "new"
>>>> and "delete" are a pair.
>>>
>>> No, in Java and C# there's no delete.
>>
>> Also, new (== creating a new Object on the heap) is a standard feature
>> in D that is needed all the time, delete (== manually destroy and
>> deallocate an Object) isn't.
> 
> As Steven also pointed out:
>> For non-garbage-collected languages, yes.  For GC languages, delete is to be discouraged (that is what the GC is for)
> 
> Which makes D special, since it claims it can do both. One would expect it to work as it advertised, without writing a whole runtime of your own.

This claim is indeed confusing. It has been there for D1 as well and I
found it kind of disappointing that you couldn't do proper manual memory
management with Objects of *any* class but just with custom classes that
defined new() and delete()...
This is better with D2 and emplace(), enabling to write simple custom
(de)allocators - as my example has proven that can be done with about 5
lines for the allocator and 2 lines for the deallocator - that can be
used for any class. In this case however delete makes no sense because
you need to use your custom deallocator anyway.

However I think the standard use of D (both 1 and 2) is to use new and
no delete and no custom (de)allocators, even though it may have been
advertised as a core feature.

Cheers,
- Daniel

On 27.04.2011 22:42, Steven Schveighoffer wrote:

> For non-garbage-collected languages, yes.  For GC languages, delete is to be discouraged (that is what the GC is for).

  delete() is 99% of the cases O(1) operation (thanks to free lists), while invocation of GC is O(?) (no one knows how many objects are pending deallocation, and when exactly it will be invoked).

  I agree that in normal applications (mostly) this is rarely an issue, but there are not normal applications, which I mentioned previously - RT & OS, and some others.

  Additionally, memory management hooks supported by the compiler are faster than any other solution (templates & co).

> Java and C# code do not have much use for delete either

  What about those coming from C++ and D1 (including D2 up to this point)?

  But, actually, I am really interested in only one thing... I agree, that some may feel discomfort using delete, but what is the reason to remove it from the language? Probably, I've missed something, but why not to leave it as is for those who need it?

/Alexander

On 27.04.2011 22:46, Dmitry Olshansky wrote:

> - there is an awful lot of operations which allocate GC memory implicitly aka arr1 ~ arr2, so it's not like you can pass the allocator and prevent the function from allocating _somewhere_ else

  This is solvable by using different runtime or class hierarchy, thus overriding "~" & co. Another option is to avoid constructs which may invoke GC (those are well-described).

> - I still fail to see how passing allocator would allow the function to decide on whether it's GC-like allocation or not, i.e. manual memory management implies the certain way function does its job (more generally the whole program, framework, module
> etc. it's not something decided at single call point)

  Again - different runtime and/or specialized class hierarchy. Custom (de)allocators are inherited, so one base class will do.

/Alexander

On 28.04.2011 2:19, Alexander wrote:
> On 27.04.2011 22:46, Dmitry Olshansky wrote:
>
>> - there is an awful lot of operations which allocate GC memory implicitly aka arr1 ~ arr2, so it's not like you can pass the allocator and prevent the function from allocating _somewhere_ else
>    This is solvable by using different runtime or class hierarchy, thus overriding "~"&  co. Another option is to avoid constructs which may invoke GC (those are well-described).

I think you might be surprised how many there are.
>> - I still fail to see how passing allocator would allow the function to decide on whether it's GC-like allocation or not, i.e. manual memory management implies the certain way function does its job (more generally the whole program, framework, module
>> etc. it's not something decided at single call point)
>    Again - different runtime and/or specialized class hierarchy. Custom (de)allocators are inherited, so one base class will do.
That's your C++ experience speaking ;) It seems you just like manual memory management in c++ and can't see other ways.
So I gather, the solution is to dump GC ? Hardly very useful. Also dropping language constructs is no go. (this 'avoid' is too vague)
OK, fighting implicit allocation. With what - refcounting? Imagine array slices and such, when can you tell there is no references to this memory block ? Well, if you know what you are doing you could try and hack druntime to use refcounting, there was talk about it.
 Anyway, I just want to make sure you get the idea that GC is the default thing in D, not 'possible under certain circumstances' thing like it is in C++.
> /Alexander


-- 
Dmitry Olshansky

On 2011-04-27 20:44, ulrik.mikaelsson@gmail.com wrote:
> Den, skrevJacob Carlborg <doob@me.com>:
>  > Yeah, that's correct. But in this case I think he actually was
> referring to the latest commit. I'm pretty sure I've heard the latest
> commit in SVN be referred to as "trunk".
>
> I'm too curious for my own good, so I had to waste some time to investigate.
>
> It seems HEAD is a meta-reference, pointing to some other reference
> (such as some other branch or a specific commit). For a full repository,
> it's also the base of the current checkout. (Or really, the index, for
> anyone else in my currently nit-picking mood).
>
> For a bare repository (I.E. without a working-copy such as you would
> find on GitHub), it seems to be whatever HEAD was in the repository that
> was initially cloned to create the bare repository.
>
> So, in the case assumed here, HEAD is the same thing as master, but it
> can really be anything (including the initial zero-commit). So "master",
> is always the last commit in the "master" branch, while HEAD can be
> anything.

Ok, I give up. But from a practical point of view and in most of the cases HEAD will be the latest commit in the current branch.

> I think "master" is always a better translation of "trunk". :)

-- 
/Jacob Carlborg

On 2011-04-27 22:28, Daniel Gibson wrote:
> Am 27.04.2011 22:13, schrieb so:
>>> 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
>>
>> With the deprecated "delete", custom allocators and such i don't see
>> much of a reason other than saving an "!" (actually we don't save a char
>> here, " " also a char :) ), and "()" if you are calling the default
>> constructor. I don't consider these points negative, quite contrary, you
>> just got rid of an arcane syntax.
>>
>> It is understandable for C++ has it. If nothing else, the lack of many
>> basic features (maybe the reason of this syntax).
>>
>> Rather then removing all together, i would drop them from language and
>> go for a library solution, if there is an obvious blocker, i also fail
>> to see it :)
>
> It'd create template bloat and uglier syntax (expecially confusing for
> people coming from about any other popular OO language) for a really
> common, standard feature.
> These drawbacks are acceptable for custom allocation and other stuff the
> average user shouldn't care about, but not for an elemental feature like
> "new".
>
> Cheers,
> - Daniel

Ruby uses "ClassName.new" to create a new instance and Objective-C uses "[[ClassName alloc] init]". Not all languages use "new ClassName".

-- 
/Jacob Carlborg

On 2011-04-28 00:15, Alexander wrote:
> On 27.04.2011 22:42, Steven Schveighoffer wrote:
>
>> For non-garbage-collected languages, yes.  For GC languages, delete is to be discouraged (that is what the GC is for).
>
>    delete() is 99% of the cases O(1) operation (thanks to free lists), while invocation of GC is O(?) (no one knows how many objects are pending deallocation, and when exactly it will be invoked).
>
>    I agree that in normal applications (mostly) this is rarely an issue, but there are not normal applications, which I mentioned previously - RT&  OS, and some others.

If you're writing an OS you would need to write your own runtime anyway.

>    Additionally, memory management hooks supported by the compiler are faster than any other solution (templates&  co).
>
>> Java and C# code do not have much use for delete either
>
>    What about those coming from C++ and D1 (including D2 up to this point)?
>
>    But, actually, I am really interested in only one thing... I agree, that some may feel discomfort using delete, but what is the reason to remove it from the language? Probably, I've missed something, but why not to leave it as is for those who need it?
>
> /Alexander


-- 
/Jacob Carlborg

On 28.04.2011 10:14, Dmitry Olshansky wrote:

> That's your C++ experience speaking ;) It seems you just like manual memory management in c++ and can't see other ways.

  This is not true, actually :) I agree, that GC is nice thing for most applications, and I really like it, but, I simply
  want to have an *option* to *control* memory allocation, if I choose to do so. Rarely, but I do need it (and not only me).

> Also dropping language constructs is no go. (this 'avoid' is too vague)

  I didn't say so - just referring to http://digitalmars.com/d/2.0/garbage.html, namely section "D Operations That Involve the Garbage Collector".

  RT & OS applications are constrained anyway, so I see no problem there. And no, "dropping GC" is not an option.

> OK, fighting implicit allocation. With what - refcounting?

  Manual management - whatever is this. malloc() with following free(), for instance - when there is no need anymore. But I prefer a bit more "natural" (not to everyone, of course) way - using delete.

  Even with GC, explicit delete may be useful (I've explained already, why).

>  Anyway, I just want to make sure you get the idea that GC is the default thing in D, not 'possible under certain circumstances' thing like it is in C++.

  Believe me, I do get that idea - using it for many years in Perl & C# :) And I am strictly "pro" GC in D as a default, just want to have more options, that's all - that's why I don't like when those options are phased out with no (obvious to me)
reason (which I want to find out).

/Alexander

Am 28.04.2011 10:28, schrieb Jacob Carlborg:
> On 2011-04-27 22:28, Daniel Gibson wrote:
>> Am 27.04.2011 22:13, schrieb so:
>>>> 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
>>>
>>> With the deprecated "delete", custom allocators and such i don't see
>>> much of a reason other than saving an "!" (actually we don't save a char
>>> here, " " also a char :) ), and "()" if you are calling the default
>>> constructor. I don't consider these points negative, quite contrary, you
>>> just got rid of an arcane syntax.
>>>
>>> It is understandable for C++ has it. If nothing else, the lack of many
>>> basic features (maybe the reason of this syntax).
>>>
>>> Rather then removing all together, i would drop them from language and
>>> go for a library solution, if there is an obvious blocker, i also fail
>>> to see it :)
>>
>> It'd create template bloat and uglier syntax (expecially confusing for
>> people coming from about any other popular OO language) for a really
>> common, standard feature.
>> These drawbacks are acceptable for custom allocation and other stuff the
>> average user shouldn't care about, but not for an elemental feature like
>> "new".
>>
>> Cheers,
>> - Daniel
>
> Ruby uses "ClassName.new" to create a new instance and Objective-C uses
> "[[ClassName alloc] init]". Not all languages use "new ClassName".
>

Ok. And probably Python doesn't as well.
However D has this C/C++/Java/C# like syntax (Objective-C probably has that as well, but anyway), i.e. curly braces for blocks, C-like syntax for functions, try {..} catch(Foo f) {..} (yeah I know C doesn't have that, but no alternative different syntax either), ... so IMHO it makes sense for D to have the same syntax as the majority of these languages for the same feature (if that syntax doesn't have big enough drawbacks like <> for templates).

Cheers,
- Daniel