On 2011-04-27 18:27, Ulrik Mikaelsson wrote:
> 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.)

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".

-- 
/Jacob Carlborg

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 (IE 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.

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

> 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 :)

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

> 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.

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.

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.

On Wed, 27 Apr 2011 16:37:49 -0400, so <so@so.so> wrote:

> 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.

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

Java and C# code do not have much use for delete either, so people coming from those languages will feel right at home without the delete keyword I would think.

-Steve

On 27.04.2011 20:21, Ulrik Mikaelsson wrote:
> 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

I presonally  think of new in D  as a shortcut for yours would be GC.new!T(...). It's the same thing as with 'foreach' and such, i.e. used often enough to deserve a keyword.

As for your suggestion, I see some problems with it:
- yours Malloc and GC artifacts already have asymmetry, imagine generic code. Also there is stack-like allocators e.g. new David Simcha's TempAlloc
- 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
- 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)

-- 
Dmitry Olshansky

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.