On Sun, 19 Apr 2015 00:50:23 +0000, weaselcat wrote:

> maybe I'm dumb in asking this, but if there was already an API for allocators in D... why is a std.allocator not being written ontop of it? it seems much more elegant to begin with.

ability to override `new` and `delete` is a big can of worms. c++ got into that, and now it's not recommended to touch that operators.

in a short: it's inflexible (you can't use two different `new` with one class, for example -- if not count the weirdo `new(5) A()` and such), you can't predict how your class will be allocated (yea, you didn't define `new` for your class... but one of it's parents did and... bam!) and so on.

so i fully understand why it's silently deprecated. yet i still don't want it to go. ;-)

On Sun, 19 Apr 2015 01:19:46 +0000, Brian Schott wrote:

> On Sunday, 19 April 2015 at 00:39:03 UTC, ketmar wrote:
>> On Sun, 19 Apr 2015 12:29:45 +1200, Rikki Cattermole wrote:
>>
>>> Awesome! Although we may need to "undeprecate" that feature.
>>
>> as it is not generating deprecation warning now, it should be fairly
>> easy: just reintroduce it into specs. i can see why it was deprecated
>> in the first place, but it's much easier to simply write "new
>> Exception"
>> instead of "allocateWithMyCoolScheme!Exception".
> 
> If you overload a class's `new`, you are deciding for your class's user how it will be allocated. I think it's better to let the programmer decide how they want the class to be allocated.

yes, i know all that... but i still want it! ;-)

On Sunday, 19 April 2015 at 02:24:06 UTC, Rikki Cattermole wrote:
> 	int[3] values = allocate!(int[3]);

Why would you ever do that? int[3] is statically allocated....


auto values = allocate!(int[])(3);

would make a lot more sense, then values would be typed perhaps to int[], but also it might be typed to something like RefCounted!(int[]) or Unique!(int[]) or something, so the requirement to deallocate is encoded right there in the type and thus known to the compiler.

But even `int[] values = new!(int[])(3);` is very similar to the built-in syntax and can do exactly the same thing - while also being changeable to a new scheme by importing a different module.

On Sun, 19 Apr 2015 01:53:41 +0000, Adam D. Ruppe wrote:

> On Sunday, 19 April 2015 at 00:39:03 UTC, ketmar wrote:
>> but it's much easier to simply write "new Exception" instead of "allocateWithMyCoolScheme!Exception".
> 
> eh i would just call it "New!Exception" where the cool scheme is in the module name. So you "import mycoolscheme;" which defines the New.
> 
> Then you can disambiguate with the usual module features if you use two schemes in the same scope. It'd be so beautiful.

ah, i keep forgetting about D ability to rename imports and detect name conflicts. too much delphi in my youth. ;-)

On 19/04/2015 2:45 p.m., Adam D. Ruppe wrote:
> On Sunday, 19 April 2015 at 02:24:06 UTC, Rikki Cattermole wrote:
>>     int[3] values = allocate!(int[3]);
>
> Why would you ever do that? int[3] is statically allocated....
>
>
> auto values = allocate!(int[])(3);
>
> would make a lot more sense, then values would be typed perhaps to
> int[], but also it might be typed to something like RefCounted!(int[])
> or Unique!(int[]) or something, so the requirement to deallocate is
> encoded right there in the type and thus known to the compiler.
>
> But even `int[] values = new!(int[])(3);` is very similar to the
> built-in syntax and can do exactly the same thing - while also being
> changeable to a new scheme by importing a different module.

I couldn't fully remember the syntax. So I went with closest I thought it was to make the point.

On 4/18/15 5:50 PM, weaselcat wrote:
> On Sunday, 19 April 2015 at 00:39:03 UTC, ketmar wrote:
>> On Sun, 19 Apr 2015 12:29:45 +1200, Rikki Cattermole wrote:
>>
>>> Awesome! Although we may need to "undeprecate" that feature.
>>
>> as it is not generating deprecation warning now, it should be fairly
>> easy: just reintroduce it into specs. i can see why it was deprecated in
>> the first place, but it's much easier to simply write "new Exception"
>> instead of "allocateWithMyCoolScheme!Exception".
>
> maybe I'm dumb in asking this, but if there was already an API for
> allocators in D... why is a std.allocator not being written ontop of it?
> it seems much more elegant to begin with.

Nah, it's not. -- Andrei

On Sunday, 19 April 2015 at 02:42:28 UTC, ketmar wrote:
> On Sun, 19 Apr 2015 00:50:23 +0000, weaselcat wrote:
>
>> maybe I'm dumb in asking this, but if there was already an API for
>> allocators in D... why is a std.allocator not being written ontop of it?
>> it seems much more elegant to begin with.
>
> ability to override `new` and `delete` is a big can of worms. c++ got
> into that, and now it's not recommended to touch that operators.
>
> in a short: it's inflexible (you can't use two different `new` with one
> class, for example -- if not count the weirdo `new(5) A()` and such), you
> can't predict how your class will be allocated (yea, you didn't define
> `new` for your class... but one of it's parents did and... bam!) and so
> on.
>
> so i fully understand why it's silently deprecated. yet i still don't
> want it to go. ;-)

I was unaware of how the override new worked, after reading the thread again it makes more sense why it's not used now.
Thanks.

On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote:
> Consider also the coming addition to the language for class reference counting methods opAddRef and opRelease.

Since it's classes we are talking about, wouldn't that mean we need to do a virtual function call each time a class reference gets assigned or goes out of scope(and twice when it gets reassigned)?

The interesting thing about this is that 'throw new ExceptionType(...)' could be reference counted. The downside of not getting rid of the 'new' overloading at some point is that it can make the operator do surprising and unexpected things, so the rationale for getting rid of it is similar to the rationale behind disallowing overloading of '&&' and '||'.

What I found more interesting is that class constructors themselves can be marked @nogc, which I never thought to do before. So whatever syntax we end up with for 'allocate with this other allocator and call this constructor' could take advantage of that. I'm not sure how that will end up looking in the end, but I am reminded of Objective C again, where allocation and construction are explicitly separated.

// Enough time in Wonderland makes this seem perfectly natural.
MyClass* foo = [[MyClass alloc] initWithNumber:3];

On Sunday, 19 April 2015 at 09:57:52 UTC, w0rp wrote:
> The interesting thing about this is that 'throw new ExceptionType(...)' could be reference counted. The downside of

What's wrong with just putting exceptions in a dedicated memory area like C++?